👋 Привет! Перед тобой свежий выпуск ✨ Community Wisdom ✨ — еженедельная рассылка только для подписчиков, в которой мы собираем самые полезные обсуждения из нашего закрытого Slack-сообщества.
Спасибо спонсору этого месяца — Clerk. Clerk позволяет запустить боевую аутентификацию мгновенно, не тратя инженерные спринты на логин/регистрацию. Всё, что нужно твоему приложению: готовые компоненты, организации для B2B-мультитенантности, встроенный биллинг подписок и ещё куча всего — плюс поддержка MCP-серверов, чтобы ИИ-агенты могли аутентифицироваться и действовать от имени твоих пользователей. Строй продукт, а не слой авторизации. Подробнее тут.
Встречи, организованные участниками сообщества — нажми на город, чтобы зарегистрироваться:
Не нашёл свой город и хочешь организовать встречу? Просто напиши @Riya в нашем Slack. Подробнее тут.
Руководитель роста (Anthropic): «Claude на данный момент растит сам себя» | Amol Avasare: YouTube, Spotify и Apple Podcasts
Я собрал кастомный Slack-инбокс. Это было проще, чем кажется. | Yash Tekriwal (Clay): YouTube, Spotify и Apple Podcasts
Вопрос: Ищу лучшие практики вайб-кодинга в командной работе. В нашей компании мы сейчас используем Claude Code и работаем довольно независимо: у каждого свой GitHub-репозиторий и деплой на Vercel, отдельно от инженерной команды. Хочу найти способы эффективнее сотрудничать и улучшить совместную работу. Если ты видел настройки или рабочие процессы, которые хорошо работают в таком контексте — буду очень благодарна за инсайты. ↗—Alice Roussel
Aaron Nichols: Мы видим ту же проблему в собственных проектах. Похоже, ты работаешь за пределами инженерной организации с этими инструментами. Тебе важнее совместная работа с коллегами по команде или взаимодействие с инженерами? Сейчас появляются новые подходы к работе и инструменты — но многое приходится нащупывать самостоятельно. Командное поведение очень сильно зависит от доступных инструментов, так что типичный путь — сначала понять, как хочешь работать, а потом найти или построить инструменты под это. Плюс подход зависит от материала, с которым работаешь. Совместная работа над документами для людей может отличаться, если ты также хочешь привлекать агентов. Совместное написание кода в команде, по-моему, становится даже сложнее — если не считать парного программирования. Куча переменных.
Несколько вещей, которые хорошо работают у нас:
Для нас главное — использовать агентов, чтобы то, над чем работаешь, было видно в общем пространстве, где другие могут задавать вопросы и участвовать.
Общее информационное пространство — это ключ. Но оно быстро зашумляется (как и кодовая база), когда агенты начинают с ним взаимодействовать. В идеале люди используют агентов, чтобы обработать изменения и фильтровать то, что им лично интересно. Для большой команды это непростая задача. Думаю, сейчас появляются системы для масштабного общего контекста с управлением, но мы особо не нашли готовых — поэтому строим своё.
Про безопасность — это требует внимания и представляет реальный риск. Есть очевидные проблемы с агентами, которые ведут себя некорректно, но есть и атаки на цепочку поставок — огромный риск сейчас, когда все собирают софт на рабочих ноутбуках. Это задача, на которую стоит выделить квалифицированных людей для стандартизированного решения, потому что подход сильно зависит от контекста организации. Вот о чём стоит подумать:
Хорошая новость — агенты с общей системой контекста и сигнализацией на самом деле становятся очень мощным инструментом на рабочем столе для распространения информации и обеспечения безопасности. Можно раздавать инструкции по настройке рабочей среды, которые решают эти проблемы. Можно проверять системы на соответствие требованиям и т.д.
Ещё одна большая проблема, которую мы видим в организациях, — нехватка времени на обучение. Если в компании люди чувствуют, что поставлять результат важнее, чем разбираться в инструментах, будет тяжело. Нужно пространство для обучения, экспериментов и «потерянной работы» в этом процессе. Выделенное время без совещаний для всей компании или команды, плюс сессии обмена опытом — что работает, а что нет — помогают людям учиться быстро. Ещё полезно найти человека, который ходит и помогает: разблокирует людей, помогает преодолеть препятствия при работе с инструментами. Этот же человек может помочь со стандартизацией и созданием инструментов, о которых я говорил выше.
Marshall: Круто! Мы проходим похожее упражнение, и мне интересно, какие паттерны появятся на разных уровнях: личном, командном, корпоративном и отраслевом.
Полностью согласен с Aaron — собственные эксперименты критически важны, чтобы увидеть, что работает. Каждая команда уникальна. Мне нравится подход «сделай → найди трение → исправь», когда паттерн рождается естественно: делаешь, точно формулируешь, что мешает, просишь Claude исправить... и так по кругу. Я написал о своём опыте с этим подходом здесь. Какие трения ты и твоя команда испытываете вокруг эффективного сотрудничества?
Alice Roussel: Это суперполезно, огромное спасибо. Уточню: мой главный фокус — кросс-командное сотрудничество за пределами инженерии. Нас недавно попросили перейти на AI-first по всей компании, и я хочу избежать ситуации, когда 100+ человек кодят каждый сам по себе. Несколько конкретных трений, которые я уже вижу:
Я начинаю думать, что решение — не навязывать процесс, а создавать: общий слой (документы, компоненты, контекст в .md), лёгкие паттерны совместной работы (когда строить одному, а когда объединять) и безопасное пространство для обучения (например, sandbox-сессии для онбординга). Интересно, видел ли ты, как команды успешно балансируют индивидуальную скорость и командный рычаг в такой среде.
Sam Montoya: Безопасность — огромная проблема, которую я наблюдаю. Будь то секреты (не повторяй за Anthropic), события, харденинг, тестовые стенды для eval или даже prompt injection — у людей пробел в практиках безопасности. Что касается освоения — это по сути управление изменениями. Просто звучит, но сложно реализовать. В предыдущей компании я создал AI Guild и проводил все ИИ-инициативы через неё. Включая стандартные процедуры, раскатки, обучение и так далее.
Gautam Banerjee: Есть несколько идей. Я использовал GitLab Pages (то же самое можно сделать в GitHub):
У нас набор Python-скриптов, которые тянут данные из Jira и Slack, мёрджи репозитория, считают метрики и генерируют один HTML-файл — самодостаточную веб-страницу с графиками и таблицами.
Этот файл автоматически публикуется по URL, который может посмотреть любой в команде, плюс можно настроить, чтобы раннер отправлял саммари за прошлую неделю или день в Slack.
«Публикация» — это бесплатный хостинг, встроенный в GitLab (и GitHub). Никаких серверов.
Каждый день в 8 утра:
GitLab автоматически запускает наши скрипты
→ Скрипты тянут свежие данные из Jira + Slack, GitLab
→ Скрипты генерируют HTML-отчёт
→ GitLab публикует его как веб-страницу
→ Команда заходит по URL и видит свежий дашборд.
Могу показать пример в личке.
Ashwin: Добавлю к тому, что сказал Gautam: если у тебя уже есть Jira, попробуй Atlassian Rovo. Он поможет превратить любые задачи из Jira в код.
Priya Mathew Badger: По поводу проблемы, когда часть людей уже освоилась, а многие — нет. Мы экспериментируем с ежеквартальным выделенным днём обучения ИИ: чтобы все установили Claude Code, прошли настройку персональной ОС, контекста, создание навыков и т.д. Могу рассказать, как пойдёт — напиши мне в личку.
Вопрос: Нанимающие менеджеры, нашли ли вы хороший способ обучать навыкам собеседования внутри команды? Не как проходить интервью в конкретной компании, а как реально оценить, справится ли кандидат с работой, и задавать вопросы, которые дают настоящий сигнал, а не отшлифованные ответы. Процессы собеседований становятся всё длиннее — больше раундов, больше участников. Но больше интервью не значит лучшие решения, если никто из панели не умеет оценивать навыки. В какой-то момент ты просто собираешь всё больше мнений на основе ощущений. Удалось ли кому-то системно передать этот навык людям, которые проводят найм? ↗—Dana Daniele
Daniel Heo-Lu: В крупных компаниях часто практикуют shadow и reverse shadow — наблюдение и практика в реальных собеседованиях. Ещё я считаю очень полезными явные критерии оценки, где чётко прописано, что считается слабым, что хорошим, а что — «хорошо для более старшего сотрудника».
Вот пример критериев оценки, которые я написал недавно для переработанного интервью:
Это привязано к нашему конкретному заданию, но суть понятна.
Miroslav Pavelek: Первый шаг — есть ли у тебя хоть какой-то письменный фреймворк/матрица для оценки навыков? Когда мы решали эту задачу, дело было в shadow-сессиях и обмене заметками, включая матрицу (мы называли её scorecard). После нескольких совместных интервью, если оценки совпадали, мы допускали менее опытного человека самостоятельно проводить собеседования.
Daniel Heo-Lu: Полностью согласен!
Dana Daniele: У нас нет матрицы — ты делал её сам? Даёшь ли список вопросов, привязанных к матрице?
Daniel Heo-Lu: Для меня scorecard и критерии оценки идут рука об руку. Я делал их сам. По вопросам у меня есть основа (главный вопрос) и несколько зондирующих (дополнительных). Основные вопросы обязательны, зондирующие — нет. Это подсказки, как копнуть глубже. Обычно я ставлю 3 основных вопроса на 45-минутное интервью, чтобы оставить время кандидату задать свои. На скриншоте — пример основного вопроса и 3 зондирующих.
Я просматриваю наши scorecard по каждому этапу и проверяю, что весь цикл собеседований покрывает нужное. Для меня это баланс кейс-стади, поведенческих вопросов/коллаборации и экспериментирования, чтобы каждого типа было достаточно. По техническим навыкам мы оцениваем мягче, а по аналитике — совсем легко. Хотели бы углубиться и туда, но пока оставляем так, чтобы не плодить бесконечные раунды.
Ben Erez: Я недавно выступал о том, как оценивать ИИ-грамотность на собеседованиях для PM, но этот фреймворк легко расширить для проектирования процесса интервью под любые навыки, которые тебе важны.
Вопрос: Лидерские офсайты могут быть потрясающими или совершенно ужасными. Чего, по-твоему, не хватало на последних трёх офсайтах, на которых ты был...? ↗—Adam Thackeray
Joshua Herzig-Marx: Настоящей работы. Многие думают, что если поиграть или поделать псевдо-работу, это улучшит реальное взаимодействие. Это как если бы лыжная команда каталась на санках для улучшения результатов. Или хоккейная команда играла в настольный футбол. Весело? Конечно. Узнать друг друга лучше? Почему нет. Реально улучшить результаты? Нисколько. Если хочешь научиться лучше работать вместе — практикуйся на настоящей работе. (Но я имею в виду не просто «делай» — именно практикуйся: составь план, выполни задачу, разбери, как получилось, повтори. Привлеки коуча, если есть такая возможность.)
Aaron Nichols: Чего я часто не вижу — подготовительной работы: определить, какой сложный результат эта группа не может достичь, когда они не в одной комнате, и приоритизировать достижение именно этого результата на офсайте. Ещё часто не хватает нормальной фасилитации от человека, который не является заинтересованной стороной в обсуждении. Я фасилитировал такие встречи для топ-команд — всегда есть план, который приходится менять на ходу. Всплывают вещи, разговоры затягиваются, и когда есть человек, чья единственная задача — следить, чтобы время тратилось на правильные разговоры ради ключевого результата — это работа, которую никто из участников дискуссии не может делать эффективно. И это меняет всё, когда можешь адаптироваться к неожиданностям и всё равно прийти к результату. Обычно разногласия о том, кого звать, возникают потому, что тема разговора и ожидаемые результаты не ясны заранее — когда они понятны, люди обычно сами знают, кто должен быть.
Joni Hoadley: Правильный состав участников. Иногда компании зовут слишком много людей. Иногда — слишком мало. В обоих случаях обычно есть те, кого позвали зря, и те, кого не позвали, но стоило бы.
Ashwin: Офсайт должен решать одну из трёх задач: сплочение команды, формирование видения или организационное выравнивание. Если пытаешься смешать все три — ничего хорошего. Лучше разделить на отдельные треки по дням. Например, вот расписание, которое хорошо работало: все прилетают в понедельник, вечером неформальные напитки. Вторник — организационное выравнивание между руководителями. Среда — день сплочения с весёлыми активностями. Четверг — кристаллизация видения от каждой группы. Пятница утром — презентации, и к обеду все разъезжаются.
Продуктивной и наполненной недели 🙏
Если кому-то из твоих знакомых будет полезна эта рассылка или сообщество, подари им подписку 💞 Есть групповые скидки, подарочные варианты и бонусы за рефералов.
С уважением,
Kiyani 👋