Обучение через чужой опыт — вполне реальная штука: мы перенимаем навыки и знания, наблюдая за другими, слушая об их ошибках, видя, что сработало. Поэтому постмортемы так хорошо помогают наращивать контекст и видеть, как другие инженеры решают проблемы. В последнее время я много думаю об обучении через чужой опыт — особенно о том, как инженеры учатся пользоваться AI.

Контента про AI хватает: разборы рабочих процессов, откровения о продуктивности, статистика экономии времени. Но когда я разговариваю об этом с инженерами, я слышу, что они пока не нашли понятного пути к инсайтам, после которых эти инструменты действительно становятся полезными. В основном они доходят до них путем проб и ошибок.

И что тревожнее, я вижу растущий разрыв между людьми, которым нравится работать с AI-инструментами, и теми, кто чувствует, что начинает отставать. Если эти инструменты и правда наше будущее — а при всех оговорках я думаю, что так оно и есть, — не хочется, чтобы кто-то остался за бортом. Самые громкие евангелисты обычно смещены в сторону довольно конкретной демографической группы. Я хочу, чтобы все профессионалы своего дела чувствовали, что они поспевают за изменениями, — и действительно успевали, а не просто действовали из страха.

Поэтому я поговорила с несколькими staff-инженерами и ведущими инженерами из разных компаний, которые каждый день используют искусственный интеллект в работе и чувствуют, что у них это неплохо получается. Никого из них я не назвала бы евангелистом: это люди, которые не спешили внедрять эти инструменты и до сих пор всерьёз переживают из-за своей причастности к экологической цене AI и политическому контексту вокруг того, кто создает эти инструменты и зачем. Но сейчас они используют AI-инструменты — в основном Claude — для большей части своей разработческой работы.

В этих интервью я преследовала цель проверить идею, которую давно обдумываю: возможно, командам сейчас не хватает регулярной встречи, где можно делиться приемами, находками и другими «ага-моментами» о том, как меняется их работа. Ниже я подробно расскажу, как это можно устроить.

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

Проблема метода проб и ошибок

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

Я спрашивала: вы делитесь приемами и находками с командой?

Ответ был: ну, вроде как. В каждой из их организаций есть какой-то аналог Slack-канала, где люди публикуют развернутые посты о своих рабочих процессах или задают короткие точечные вопросы вроде: «Как заставить Claude сделать X?» Но сейчас эти инженеры редко читают такие каналы, а польза от них постепенно снижается. Почему?

Мир меняется слишком быстро. Пост о workflow недельной давности уже может устареть: три вещи, о которых там говорилось, с тех пор успели измениться. Внутренние правила и ограничения меняются так же быстро, и инженерам не хочется собирать узкоспециализированные решения для проблем, которые уже на следующей неделе может закрыть новый внутренний инструмент или обновление от команды devtools. И контекст решает всё: советы от человека из другого конца компании могут никак не подходить к тому, как ваша команда работает в своём углу кодовой базы.

У инженеров, с которыми я говорила, есть сильные внутренние связи и коллеги, которым они доверяют настолько, чтобы обмениваться своими приемами. Но никто не описал формат «один ко многим», где они регулярно учатся эффективнее использовать эти инструменты. На это есть несколько причин:

• Самые заметные участники обсуждений часто оказываются не самыми практичными, а просто самыми увлеченными или склонными к саморекламе.

• В некоторых организациях возникает ощущение «секретного соуса» — особенно там, где руководство заметно поощряет самых быстрых и AI-грамотных инженеров. Когда продуктивность воспринимается как игра с нулевой суммой, люди начинают придерживать рабочие приемы при себе.

• Рабочие процессы, построенные на этих инструментах, могут нести в себе риск. Человеку может быть комфортно с конфигурацией, которую он собрал для себя, но он не решается рекомендовать её другим: вдруг она сломает им окружение.

• Иерархия и статусные различия тоже играют роль. Некоторые люди, особенно недавно пришедшие в индустрию, не решаются сказать: «Я сделал это с помощью AI», потому что чувствуют себя при этом самозванцами, даже если все вокруг делают то же самое.

• А иногда люди просто не знают, как отреагирует коллега. Не начнет ли он читать лекцию о состоянии индустрии? Не бросит ли пренебрежительное «ну очевидно же, просто используй для этого Claude»? Из-за этой непредсказуемости проще вообще не открывать такую дверь.

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

Встречи для обмена опытом

Формат простой: это вариация классических встреч в духе show & tell.

• Принимать участие необязательно, но если пришел — участвовать активно.

• В начале своими словами объясните цель встречи.

  • У меня это звучало бы примерно так: «Всё меняется очень быстро. Мне хотелось, чтобы у нас была возможность делиться тем, чему мы учимся как команда»

• Затем каждый по очереди делится одним открытием, которое произошло у него за последнюю неделю благодаря работе с AI в каком-либо виде. Открытием или «ага-моментом» можно считать момент, когда вы чему-то удивились или что-то поняли. Это может быть что-то совсем небольшое: новый способ сохранять промпты или осознание, что вы совершенно неправильно представляли себе, как работает часть кодовой базы, — и узнали об этом только потому, что спросили Claude.

• После каждого рассказа группа реагирует так, как принято в вашей команде: например, эмодзи, реакцией или уточняющим вопросом. Смысл в том, чтобы дать сигнал: это было ценно услышать.

• После реакции поддержки вопросы только приветствуются. Так и происходит обучение.

• Делятся все. Руководитель тоже.

В зависимости от размера команды такая встреча должна уложиться до часа.

Будьте хорошим ведущим встречи

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

Если кто-то говорит слишком расплывчато — делится результатом, но не способом, — задавайте уточняющие вопросы. Вам важно услышать, какое «как» стояло за этим инсайтом. Если человек продолжает уходить от ответа, поговорите с ним потом один на один. Без осуждения: скорее всего, дело в страхе.

Если кто-то регулярно пропускает встречу, отдельно уточните, что происходит. Некоторым действительно комфортно учиться самостоятельно, и это нормально: эта встреча для тех, кто хочет учиться через чужой опыт. Не всем это нужно, и это тоже нормально.

Самые ворчливые участники в со временем оттают. Они ворчат не просто так: их может раздражать безопасность или ограничения devtools (я сейчас очень сочувствую людям из этих команд!), тревожить то, что происходит с их работой, или по-настоящему беспокоить этическая сторона вопроса. Стабильное, безопасное пространство, где ставки невысоки, а маленькие открытия замечают и поддерживают, помогает и им — даже если нужно несколько встреч, чтобы это сработало.

По задумке люди будут узнавать на таких встречах не только то, как остальные используют AI. Человек, который показывает, как нашел девять версий функции оформления заказа, заодно невольно показывает всем остальным, как устроена часть checkout-флоу и почему повторяемые паттерны полезны. Формально встреча называется «учимся работать с AI», но результат — особенно для тех, у кого пока не накоплен контекст по этой части системы, — может оказаться гораздо шире.

Читайте по теме:

- «Как работают ИИ-агенты для разработки»
- «Когда сотрудник тормозит команду: как говорить с ним прямо, но без давления»

Конечно, всё это работает только в том случае, если люди действительно чувствуют себя достаточно безопасно, чтобы прийти и поделиться.

Психологическая безопасность

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

• Их рабочий процесс кажется им конкурентным преимуществом, от которого они пока не готовы отказаться.

• Кто-то в команде уже раньше выражал раздражение по поводу внедрения AI, того, как с этим работает руководство, и так далее.

• Они боятся отстать — или выглядеть менее опытными в работе с этими инструментами по сравнению с другими коллегами.

Всё это понятно. В культуре принудительного ранжирования сотрудников не хочется отдавать своё преимущество конкурентам. В команде с противоречивым отношением к AI-инструментам не хочется задеть коллегу, который против внедрения. А когда вы сами пока не очень уверенно чувствуете себя с новой технологией, начинать с рассказа о собственных ошибках ощущается небезопасно.

Если вы руководитель и ведете такую встречу, прямо скажите об этом в самом начале. На практике это может звучать примерно так:

У меня у самого неоднозначное отношение ко всему этому. Возможно, у вас тоже.

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

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

Я надеюсь, что эти встречи помогут снизить нагрузку от постоянной адаптации, пока всё вокруг меняется. И надеюсь, что мы сможем поддерживать друг друга во всех чувствах, которые возникают в это совершенно безумное время.

Когда и если встречи станут регулярными, следите за тем, как люди реагируют друг на друга и чем делятся. Заметно воодушевляйтесь, когда кто-то рассказывает об ошибке, на которой научился. Находите, что отметить в каждом открытии, каким бы маленьким оно ни было. Сначала это будет казаться немного искусственным. Потом станет менее искусственным. Правда.

Много лет назад, когда я вела еженедельные демо-встречи в компании Etsy, мы устраивали короткий раунд аплодисментов после каждого выступления — каким бы маленьким оно ни было. Даже руководители могли показать что-то совсем будничное, например созданное приглашение в календаре, и все смеялись и хлопали: ну да, типичная менеджерская работа. Но это было важно. Каждому доставалась толика внимания, участвовали все, и иерархия в команде немного сглаживалась. Вся команда приходила каждую неделю по своей воле, потому что там правда было приятно находиться. Именно к этому мы и стремимся.

Разговор об AI в команде редко сводится только к выбору инструмента. Руководителям приходится объяснять изменения, договариваться с коллегами и создавать формат, в котором можно безопасно обсуждать находки и ошибки. Продолжим разбираться в этих задачах на бесплатных уроках:

• 16 июля, 20:00. «Как CTO говорить с бизнесом и командой на одном языке». Записаться

• 21 июля, 20:00. «Разработка ИИ-приложений с Claude Code». Записаться

• 22 июля, 20:00. «Операция „Воркшоп“: как получить поддержку руководства для новой инициативы». Записаться