⚡️ Практический гайд по AI-adoption для руководителей Ну что, готов горячий пирожок — мой гайд о том, как внедрять AI в ежедневную работу команд. За последний год разговор про AI внутри компаний сильно изменился. Нам нужно понять, как сделать так, чтобы новые инструменты действительно вошли в работу, и задача руководителя здесь — помочь своим людям, создать нужную среду, дать доступ к инструментам, научить, самому стать примером. Меня в процессе AI-adoption мотивирует вот какая мысль одного моего коллеги: ИИ всё усиливает, и хорошее, и плохое, и порядок, и хаос. Если в команде понятные процессы, нормальные доступы, сильная экспертиза и культура обмена знаниями — AI может всё это заметно усилить. Если процессы разваливаются, контекст живёт в головах, а инструменты выдаются как попало — массовый adoption, скорее всего, просто масштабирует этот хаос. Поэтому гайд — рабочая карта того, как помочь своей команде освоиться в новой рабочей реальности, где умение работать вместе с ИИ уже стало базовым навыком. Мы в Яндексе сейчас проходим этот путь в очень большом масштабе. Что-то уже умеем делать системно, какие-то первые подходы пришлось пересобрать, а часть практик всё ещё проверяем на ходу. В гайде я собрала то, что оказалось полезным у нас: — с чего начинать adoption в команде; — как искать первые рабочие кейсы; — зачем нужны AI-champions и амбассадоры; — почему обычное обучение часто не работает; — какие инструменты и условия нужны людям; — что имеет смысл измерять, а что легко превратить в бессмысленный KPI. Там, где это полезно, добавила практики других технологических компаний — как ещё один способ сравнить подходы. Гайд адаптирован для чтения с мобилки, навигация по разделам кликабельная. Без смс, без ботиков, только за ваши сердца 💙 @technohumanist

Попытки разорвать порочную практику и не работать в выходные в этом августе терпят полный крах. Ранним утром воскресенья заканчиваю вычитывать корректорскую правку из издательства нашей книги «Суперкоманды»✍️ Невероятное ощущение, когда твой многомесячный труд обретает форму. В ноябре мы с Леной Черниковой, сидя в Горыныче, задумали написать вместе книгу о том, как разные суперсилы проявляются в командах и к чему это ведет. Потом было ощущение ужаса от того, как мы вообще это сделаем, часы зумов и недели сидения с текстом и редактурой. И вот. Обложки пока нет, но книга на верстке в МИФ, в октябре будет презентация в Ноодоме. Ну и I’m halfway through my second book. Ее презентация будет в ноябре, а рукопись надо успеть сдать до 10 сентября. Что же, продолжаем рабочие выходные. @karpovaventures✍️

Басня: система и ее части Одна автобусная компания решила создать «лучший в мире автобус». Они разобрали лучшие машины конкурентов, взяли самый надежный двигатель от одной марки, лучшую подвеску от другой, идеальную коробку передач от третьей. Когда они попытались собрать всё вместе, детали даже не подошли друг к другу. Система - это не сумма её частей, а продукт их взаимодействия. Пример в IT У вас четыре продукта. Если вы наймете лучшего UX-дизайнера для Продукта А, лучшего data-инженера для Продукта Б и лучшего маркетолога для Продукта В, но заставите их работать изолированно, ваш портфель не станет лидером рынка. Или другой пример: попытка взять «лучшие практики» из разных фреймворков (Scrum, SAFe, Basecamp Shape Up) и слепо объединить их в один процесс без учета культурного контекста компании приведет к коллапсу разработки. Вывод Улучшение отдельных частей системы может ухудшить систему в целом. Фокусируйтесь на интерфейсах взаимодействия между вашими продуктами и командами, а не на локальной эффективности каждого из них. P.S. Кайфую от системной логики. Божечки, почему я так долго откладывал это обучение😍 #продуктовыйпуть

💁‍♀️ Просматривала вчера новый Agile Practice Guide, и там была отсылка к Google’s Project Aristotle. Они исследовали 180 команд, чтобы понять, какие факторы делают команды эффективными. Главным из них оказалась — психологическая безопасность (psychological safety). Что она подразумевает, поговорим попозже. А сейчас интересно другое — Google НЕ нашёл значимой связи между эффективностью команд и: - Совместной работой в одном месте - Принятием решений строго консенсусом - Экстраверсией участников команды - Индивидуальной результативностью - Объёмом нагрузки - Позицией членов команды - Размером команды - Стажем работы Ну, про размер команды, конечно, очень спорно, но им виднее...)

Борис Чёрный поделился у себя в твиттере инсайтом, как меняются роли в разработке продуктов:

По мере того как инженерия, продукт, дизайн, DS и другие функции трансформируются в роли нового типа, я размышлял о том, как могут эти роли выглядеть в будущем. Например, глядя на команду Claude Code, я вижу, как мне кажется, пять архетипов: 1. Prototyper: придумывает совершенно новые идеи; много их генерирует, и большинство так и не доходит до релиза 2. Builder: быстро превращает прототип или идею в production-grade продукт и инфраструктуру 3. Sweeper: приводит в порядок интерфейс, упрощает код и систему, убирает лишние фичи, оптимизирует производительность 4. Grower: берёт уже построенный продукт и итерациями улучшает его Product-Market Fit 5. Maintainer: отвечает за зрелость и масштабируемость системы — безопасность, надёжность, скорость и эффективность Люди могут совмещать несколько ролей, иногда три. Я также замечаю, что эти роли не привязаны к должности: в Anthropic одни дизайнеры соответствуют категории 1, другие — 2, третьи — 3. И то же самое с инженерами, продакт-менеджерами и DS. Здоровой команде нужен микс архетипов — в зависимости от продукта: • Новому продукту до PMF нужны люди, сильные в 1+2+3 • Растущему продукту, нашедшему PMF, нужны 2+3+4 и немного 5 • Продукту с прочным PMF нужны 3+4+5 и немного 2 Возможно продуктовые роли будущего будут выглядеть именно так — а не как сейчас, привязанные к конкретной специализации?

→ https://x.com/bcherny/status/2071379474277613732