Как Copilot используется в энтерпрайзе

Сразу предупреждаю – исследование, хоть и проводилось Accenture, но спонсировалось GitHub, поэтому к его результатам надо относиться с большой долей скептицизма.

👉67% участвовавших в исследовании разработчиков используют Copilot ежедневно.
👉Половина опрошенных говорит, что для них Copilot был супер полезен, еще 30% – просто полезен.
👉Среди группы, пользовавшейся Copilot, количество PR выросло на 9%, а рейт прохождения кодревью – на 15%.
👉Качество кода вроде как тоже поднялось. Процент успешных билдов у тестовой группы на 84% выше.
👉Что касается релевантности – 30% саджестов от Copilot принимались разработчиками, и в итоге 90% участников закоммитили сгенерированный код.
👉95% участников сказали, что благодаря Copilot они получают от программирования больше удовольствия.

Вы можете провести аналогичное исследование и у себя в компании, GitHub опубликовал целую методичку для этого.

Самое непрофессиональное поведение, которое вы встречали у новичков

Поделитесь историями о том, с какими самыми странными и непрофессиональными примерами поведения вы сталкивались от людей, которые только-только вышли к вам на работу.

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

Как тимлиду и менеджеру найти работу

Год назад мы проводили исследование тимлидов, и среди прочих вопросов спрашивали про то, почему вообще руководители рассматривают возможность смены работы. Топ-1 причина с большим отрывом – деньги. За ней шел кластер из трех причин – неудовлетворенность какими-то аспектами работы в текущей компании, поиск интересных задач и желание релоцироваться.

При этом, найм тимлида со стороны – не самая частая история на рынке. Еще несколько лет назад я подбивал аналитику, из которой было видно, что только в 14% случаев тимлидом становятся люди со стороны.

Короче говоря, трудоустройство тимлида или ПМ – вопрос нетривиальный. Если вы тоже хотите больше денег, найти для себя новых интересных задач, или релоцироваться, но не понимаете, как повысить свои шансы в найме, посмотрите на интересный проект от EnterAgility под названием "Карьерный Апгрейд". В чем суть – это что-то типа акселератора, в котором продуктом выступает ваша карьера, а прокачать его помогают 16+ крутых экспертов. Вот как выглядит процесс:

👉С вас подробно собирают ожидания по новому месту работы и все связанные хотелки.
👉Для вас проводят ассессмент навыков, чтобы понять, каких скиллов не хватает, и что нужно подкачать.
👉Вам помогают составить несколько вариантов резюме, подходящих для вакансий разного типа.
👉С привлечением настоящих нанимающих менеджеров вас будут гонять по тестовым интервью.
👉Если получению работы препятствуют какие-то внутренние блокеры, подключается коуч. А дополнительную поддержку дают мастермайнды с обменом опытом с другими участниками акселератора.

🔗 Если стало интересно, переходите на сайт и записывайтесь на бесплатную консультацию

Реклама. ИП Блик Сергей Федорович, ИНН 666300164407, erid: 2SDnjdPStY9

Как получать buy-in

Разница между пассивным согласием и buy-in в том, что в случае второго вовлеченные люди не просто не мешают вам, но активно помогают. Вот признаки, по которым вы можете понять, что ваш план получает именно buy-in, и людям на него не все равно:

👉На ревью пропозала люди делают конкретные предложения по улучшению.
👉Пропозал включает в себя трейд-офф. То есть, чтобы он был реализован, людям от чего-то надо в явном виде отказаться.
👉Ваш пропозал включает в себя детальный план по его реализации. Соглашаться с чем-то абстрактным легко, а вот согласие со списком конкретных шагов – другое дело.
👉Вы встречаете сопротивление по каким-то из пунктов плана.

Помимо этих признаков в статье есть и советы, как этот buy-in получить, но там все стандартно – объясните проблему, фокусируйтесь на том, что вы хотите изменить, а не как, дайте людям возможность самим предложить план изменений. Короче, классика.

Как использование AI влияет на безопасность

Чтобы сбалансировать вторничный пост про то, какими счастливыми становятся использующие Copilot разработчики, держите независимое исследование того, как работа с AI ассистентом влияет на безопасность кода.

👉Тестовая группа с доступом к AI пропускала больше уязвимостей, чем группа без доступа к нему.
👉При этом та же тестовая группа была более уверена в том, что их код не содержит уязвимостей.
👉Чем больше усилий разработчик вкладывал в подготовку промпта и настройку ассистента, тем ниже была вероятность того, что он пропустит уязвимость.

Спасибо Виталию Шароватову за наводку!

Почему заботиться о людях выгодно для бизнеса

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

👉Разница в продуктивности между счастливыми и несчастливыми сотрудниками достигает 4 раз.
👉Продуктивность работы после 50 часов в неделю критически падает, а после 55 часов и вовсе съедает эффективность.
👉Закон Йеркса-Додсона: люди достигают наивысших результатов в условиях умеренной мотивации. Сочетание высокой мотивации и удовлетворения от работы очень часто приводят к тому, что люди незаметно для себя доходят до критических уровней выгорания.
👉Эффект Хоторна: в ответ и на действительно грамотные решения, и на всевозможную вытворяемую менеджером глупость большинство сотрудников на всякий случай начинают лучше работать. Чаще всего недолго, но лучше.
👉Выгоревший сотрудник работает в среднем на 15-20% хуже обычного, в 25% случаев вообще теряет интерес к работе и в 2,6 раз чаще выходит на рынок труда.

Библиотека инструментов фасилитатора

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

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

Ближайшее Fast Track мероприятие:

• 8–10 июня — для менеджеров продукта, офер за 3 дня в команду Вертикалей.

Зарегистрироваться

Что ожидается от топ-менеджеров

1️⃣Ратифицировать решения

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

2️⃣Обеспечивать соблюдение ценностей и культуры компании

Ценности – это не то, что наемные консультанты пишут на стенах переговорок. Это набор правил, которыми люди руководствуются в ситуациях, в которых может быть несколько вариантов действий. Именно эти правила используются топ-менеджером в предыдущем пункте при оценке предложенного решения.

Чем полезны скрам-мастера

В Вастрик Клубе обсуждают, кому и когда вообще пригождался скрам-мастер. В целом все по классике:

👉Определение роли скрам-мастера непонятно и путается с другими менеджерскими позициями
👉В большинстве случаев полноценный выделенный скрам-мастер скорее бесполезен, как отдельная роль в команде пользу приносит, но только при условии наличия нужной квалификации.
👉Самые явные примеры пользы – настройка базовой процессной и культурной гигиены в не очень зрелых командах.

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

Как сделать стратегию читаемой

Каждый раз, когда я пишу стратегию по заветам книги "Хорошая стратегия, плохая стратегия", я получаю документ со следующей структурой:

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

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

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

Will Larson предлагает довольно очевидное решение, до которого я сам не додумался – придерживаться описанной выше структуры при написании стратегии, но отрефакторить документ для тех, кто будет ее читать, перенеся в самое начало принципы, затем – план действий, и только в самом конце – обзор происходящего, диагноз и контекст.

Как может выглядеть идеальный процесс обучения

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

Andy Matuschak, супер-известный исследователь в области обучения, рассказал про свое видение того, как может выглядеть идеальный процесс получения новых знаний, объединяющий в себе две школы – тех, кто топит за неявное обучение в процессе работы и тех, кто топит за управляемое осознанное обучение. И важная роль в этом процессе отводится AI, который разблокирует кучу возможностей для его персонализации.

Вот основные идеи:

👉В процесс обучения на своем проекте можно добавить элементы направляющего обучения как раз с помощью AI, который знает все про текущий уровень знаний человека, его интересы, и имеет доступ к происходящему на компьютере. Условно говоря, начинаете делать какой-то проект в новой области, а AI сразу же в режиме диалога дает релевантные подсказки и кусочки нужной теории, как в виде текста, так и в виде интерактивных демок, где это имеет смысл.
👉В тех случаях, когда требуется классическое обучение – скажем, при чтении какого-то учебника, такой AI может учитывать контекст проекта, над которым вы работаете, подсказывать, на какие куски теории обратить внимание, и приземлять ее на релевантные примеры. А в идеале – строить персонализированный learning track.
👉Доказанный способ сохранить новые знания в долгосрочной памяти – регулярно к ним возвращаться. AI может существенно улучшить опыт работы с Anki-карточками, периодически модифицируя и миксуя задаваемые вопросы, подстраиваясь под то, сколько времени вы готовы выделить на повторение в каждый конкретный день. Кстати, в самой статье приведены результаты офигенного эксперимента, показывающего реальную ценность repetition-based learning.

Я очень рекомендую почитать полный транскрипт доклада и посмотреть демки – выглядит как идеальный способ обучения чему-то. Кажется, для достижения этого даже не нужно использовать облачные LLM, и локальной модели с долгосрочной памятью должно хватать.

Рекрутеров можно заменить броском монеты

Ребята, которые делают сервис мок-собеседований interviewing.io провели офигенный эксперимент. Они попросили 76 технических рекрутеров отсмотреть по 30 резюме, и ответить на два вопроса:

1️⃣Позвали ли бы вы этого кандидата на собеседование?
2️⃣Какая вероятность того, что этот кандидат пройдет техническое собеседование?

Ответы рекрутеров сравнивали с реальными данными о том, с каким успехом эти кандидаты проходили мок-интервью. При этом отдельные рисерчи уже показали высокую корреляцию между прохождением таких типов интервью и последующим наймом. Короче, выводы такие:

👉Рекрутеры правильно решают пригласить кандидата на интервью только в 55% случаев. По сути, аналогично броску монеты.
👉Кандидаты, которым рекрутеры дали 0-5% вероятность прохождения интервью, на самом деле успешно прошли его в 47% случаев.
👉Кандидаты, в успешности интервью которых рекрутеры были уверены на 95-100%, прошли интервью только в 64% случаев.
👉В среднем разница в оценке вероятности прохождения интервью для одного и того же кандидата между двумя рекрутерами – 41%.
👉Декларируемые рекрутерами причины отказа от резюме не соответствуют реальным предикторам отказа.
👉Обученные на коленке ML-модели показали заметно более точные результаты в оценке резюме.

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

Как работать с друзьями

Кажется, я еще не рассказывал в канале историю своего первого увольнения. Я работал в небольшой студии разработки обычным мобильщиком. В какой-то момент наш руководитель начал искать дизайнера в команду, и я порекомендовал ему своего давнего приятеля, с которым у нас за плечами было уже несколько запущенных пет-проектов. Проблемы с ним начались практически сразу же. Например, он часто не появляться в офисе половину дня, а вторую – спал в гамаке. Потом в какой-то момент он решил откосить от армии, и несколько дней у всех в офисе пытался занять деньги на покупку военника. Ну и, главная проблема – продалбывал абсолютно все сроки и договоренности.

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

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

Так вот, к чему эта подводка. На днях вышел новый выпуск подкаста "Три тимлида заходят в бар", который бьет прямо в эту тему – как работать с друзьями, нанимать их, расставлять границы, и, если все пошло плохо, увольнять. Хороший подкаст, послушайте!

Подборка книг по продакт-менеджменту

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

👉Chrossing the Chasm, объясняющая, как выглядит цикл адопшна новых продуктов и технологий.
👉Escaping the Build Trap, про то, как работают фиче-фабрики, и как это прекратить.
👉Sprint, хороший фреймворк, с помощью которого всего за неделю вы можете получить работающий прототип своей идеи.

Как управлять bottleneck командой

Частый организационный антипаттерн в большой компании – команда, стоящая на критическом пути сразу большого количества проектов. Например, такая команда может отвечать за какой-то общий API, доработки в котором регулярно требуются многим общим клиентам. Или отвечать за все базы данных.

На увеличение time to market влияет не только сам факт обособленности команды, но еще и то, что с ростом компании такие команды не всегда растут теми же самыми темпами. А это влечет за собой рост количества клиентов, размазывание ресурсов команды еще более тонким слоем, растущий бэклог невыполненных задач и еще более растущий TTM.

Несколько советов из статьи для менеджеров таких команд:

👉Проблемы такого рода часто растут из архитектуры. Попробуйте привлечь нескольких независимых людей, чтобы они со стороны оценили вашу ситуацию и подсветили бы какие-то слепые пятна.
👉Найдите способ держать ваш менеджмент в курсе ситуации в команде, того, по каким причинам вы не справляетесь со всеми запросами, и как выстраиваете приоритизацию. Вам нужно получить защиту от так называемого stakeholder bullying, когда разные менеджеры с громкими тайтлами будут пытаться продавливать вас, чтобы их фича вышла в топ бэклога.
👉Подумайте, есть ли возможность перейти из сервисной в платформенную команду – и вместо выполнения работы за других людей давать им удобную платформу, которой они смогут пользоваться целиком без вас.
👉Рассмотрите подход внутреннего open source, когда люди из других команд могут сами делать нужные им фичи, а вы только принимаете PR.
👉Установите режим дежурств, в котором все входящие запросы к команде в каждый момент времени направляются строго на одного человека.