Cтарая кринжовая история про найм.
2018 год. Москва. Чертаново. Офис QIWI. Собеседуем испанца Антонио.
Сейчас пишу и как-то самому не верится.
8 лет я держал в себе эту историю, хочу наконец-то поделиться.
Уже прошло достаточно много времени, и не существует компании, которой эта история могла бы нанести вред.
Итак, у нас была стажёрская программа, для которой я когда-то написал тестовое задание и выложил его на GitHub. Суть простая: пишешь 100 строк кода по примеру, открываешь pull request, получаешь ревью и приглашение на интервью.
Программа уже закончилась, тестовое лежало себе на гитхабе, никого не трогало.
И тут внезапно прилетает PR.
Человек нашёл это тестовое, сделал и приложил сопроводительное письмо на английском в стиле:
«Я всё сделал, давайте меня нанимать».
Увидев письмо на английском, я ессно что-то заподозрил.
Смотрю LinkedIn — испанец, мидл. Антонио.
Ни. Хрена. Себе.
Привели его в офис, погоняли по технике, разговаривали по-английски. Всё выглядело нормально.
Вы спросите, что Антонио забыл в Чертаново? Ответ — простая человеческая любовь. Он хотел научиться говорить по-русски, чтобы лучше понимать свою жену.
И я уже начал думать:
«Так, у нас, конечно, вся команда русскоязычная. Но ребята продвинутые, по-английски говорят. Документацию где-то адаптируем. В чатах начнём писать на английском. Нормально, справимся».
Сейчас, оглядываясь назад, понимаю что это была глупость. Из-за любопытства и желания подтянуть английский я собирался обречь команду на большие накладные расходы и значимое снижение эффективности.
Согласовал со всеми и запустили процесс найма.
И тут выясняется:
У человека ВНЖ без права на работу. И он рассчитывал, что мы ему поможем с этим, как приличная компания. А мы такое не умели. 🤦
Пу-пу-пу.
Пришлось писать самый кринжовый отказ в моей жизни. Мол «чувак, ты молодец, спасибо что потратил на нас кучу времени. Мы бы тебя с радостью наняли, но не умеем оформлять иностранцев».
Аж самому от себя мерзко.
Я тогда ещё сделал отдельную глупость — написал причину отказа. За это мне настучали по башке HRBP. Потому что такие причины отказа нельзя писать как попало в личку, — кандидат может засудить.
Поэтому, чтобы усилить кринжовость ситуации, я удалил причину отказа, отредактировав сообщение и подставив «Here was the reason».
Часто жалуются, что кандидату не дают развернутый фидбэк после собеседований. Я тоже не понимал, а в тот момент как понял. Это жиза, а не то, что вас хотели принизить или не уважают.
Антонио, прости. Я был молод и глуп. А теперь волею судеб мы с тобой поменялись местами, и уже я — иностранец, пытающийся ассимилироваться.
Специально для этого поста включу реакции 🙈😨😡🗿
P.S. Сейчас у Антонио всё хорошо — судя по линкедину, работает в Мадриде на Telefonica — самый крупный телеком Испании.
2018 год. Москва. Чертаново. Офис QIWI. Собеседуем испанца Антонио.
Сейчас пишу и как-то самому не верится.
8 лет я держал в себе эту историю, хочу наконец-то поделиться.
Уже прошло достаточно много времени, и не существует компании, которой эта история могла бы нанести вред.
Итак, у нас была стажёрская программа, для которой я когда-то написал тестовое задание и выложил его на GitHub. Суть простая: пишешь 100 строк кода по примеру, открываешь pull request, получаешь ревью и приглашение на интервью.
Программа уже закончилась, тестовое лежало себе на гитхабе, никого не трогало.
И тут внезапно прилетает PR.
Человек нашёл это тестовое, сделал и приложил сопроводительное письмо на английском в стиле:
«Я всё сделал, давайте меня нанимать».
Увидев письмо на английском, я ессно что-то заподозрил.
Смотрю LinkedIn — испанец, мидл. Антонио.
Ни. Хрена. Себе.
Привели его в офис, погоняли по технике, разговаривали по-английски. Всё выглядело нормально.
Вы спросите, что Антонио забыл в Чертаново? Ответ — простая человеческая любовь. Он хотел научиться говорить по-русски, чтобы лучше понимать свою жену.
И я уже начал думать:
«Так, у нас, конечно, вся команда русскоязычная. Но ребята продвинутые, по-английски говорят. Документацию где-то адаптируем. В чатах начнём писать на английском. Нормально, справимся».
Сейчас, оглядываясь назад, понимаю что это была глупость. Из-за любопытства и желания подтянуть английский я собирался обречь команду на большие накладные расходы и значимое снижение эффективности.
Согласовал со всеми и запустили процесс найма.
И тут выясняется:
У человека ВНЖ без права на работу. И он рассчитывал, что мы ему поможем с этим, как приличная компания. А мы такое не умели. 🤦
Пу-пу-пу.
Пришлось писать самый кринжовый отказ в моей жизни. Мол «чувак, ты молодец, спасибо что потратил на нас кучу времени. Мы бы тебя с радостью наняли, но не умеем оформлять иностранцев».
Аж самому от себя мерзко.
Я тогда ещё сделал отдельную глупость — написал причину отказа. За это мне настучали по башке HRBP. Потому что такие причины отказа нельзя писать как попало в личку, — кандидат может засудить.
Поэтому, чтобы усилить кринжовость ситуации, я удалил причину отказа, отредактировав сообщение и подставив «Here was the reason».
Часто жалуются, что кандидату не дают развернутый фидбэк после собеседований. Я тоже не понимал, а в тот момент как понял. Это жиза, а не то, что вас хотели принизить или не уважают.
Антонио, прости. Я был молод и глуп. А теперь волею судеб мы с тобой поменялись местами, и уже я — иностранец, пытающийся ассимилироваться.
Специально для этого поста включу реакции 🙈😨😡🗿
P.S. Сейчас у Антонио всё хорошо — судя по линкедину, работает в Мадриде на Telefonica — самый крупный телеком Испании.
🙈55❤🔥38🤣18🗿13👍11😨9❤6🌚3🔥1🐳1
70% неприятной работы
Все знают, что быть тимлидом — это примерно так:
— Сидишь в кресле
— Двигаешь задачки по доске
— Говоришь людям, что делать
— Иногда мудро смотришь в окно
— Шутишь несмешные шутки и над ними всё равно смеются
Потом тебя повышают до CTO, потому что ты хорошо двигал задачки.
Хрен там.
Большая часть работы тимлида — это работать с неприятными вещами, которые раньше проходили где-то рядом, а теперь стали твоей проблемой.
По моим наблюдениям, у многих ребят при переходе из разработчика в тимлида резко меняется процентное соотношение приятной и неприятной работы.
Условно, было 80%/20% , а стало 30%/70%. Ниже соберу часть неприятностей работы тимлида, чтобы вы могли подумать, а надо ли вам оно.
📌 Нужноругать людей быть требовательным
Люди косячат и тебе нужно давать обратную связь.
Не булшит-бургер «ты молодец, но вот тут надо получше», а конкретно:
«Вот здесь работа сделана плохо. Вот факты. Вот последствия. Вот что нужно изменить».
Человеку неприятно.
Тебе тоже неприятно.
Если вы получаете корректирующий фидбек от руководителя — знайте, ему эта часть работы не доставляет удовольствия. Ну только если не человек с отклонениями, но предположим что орущего социопата вы сможете отличить и послать нахер.
📌 Люди ошибаются
Иногда ты видишь, что человек собирается наступить на грабли.
И тебе нужно не побежать всё чинить, а дать ему ошибиться, чтобы он научился.
А потом помочь разгрести последствия, потому что отвечать за результат всё равно тебе.
Сложность в том, что чем выше грейд сотрудника, тем больнее обычно грабли и более долгосрочные последствия ошибки.
— Ошибка стажера фиксится в течение дня. Передаю привет всем менторам стажеров, которым сложно дать человеку ошибиться, потому что «надо всё сделать нормально с первого раза».
— Ошибка сеньора — квартал+. И тут тимлиду уже реально важно уметь отличить критичную проблему от минорной.
— Ошибка тимлида проявляется только через 9 месяцев, и еще поди осознай, что это вот то принятое 9 месяцев назад решение. Проблема в том, что тимлидов обычно никто не спасает от хождения по граблям 😅 И никто не помогает простроить цепочку поиска руткоза / ошибочного решения. В этом плане обучение тимлида — дело рук самого тимлида.
📌 Люди чего-то хотят, но не всегда понимают зачем
— Хочу расти.
— Окей, а зачем?
— Ну Вася вырос.
— Окей, а тебе зачем?
— Ну… надо.
Пу-пу-пу.
И дальше ты пытаешься понять, это денежная мотивация, желание лычки, или просто человеку скучно.
И вот ты уже персональный психолог и коуч — помогаешь сотруднику понять, чего же он хочет.
📌 Люди ноют
У каждого есть проблемы, тревоги, конфликты, ожидания, усталость, ипотека, собака, переезд, сложный проект, непонятный продукт, плохое настроение и ощущение, что всё бессмысленно.
Когда ты внутри команды, ты видишь только свою боль.
Когда ты тимлид, у тебя в голове девять чужих болей. Ты не должен быть психологом для каждого, но должен поддерживать доверительные отношения и уметь «оказать первую помощь».
Такое вот насильное расширение сознания.
📌 Людей иногда приходится увольнять
Не в первый месяц.
Может быть, не в первый год.
Но если вы идёте в менеджмент, надо понимать: когда-нибудь придётся.
Или увольнять, или сокращать, или объяснять непопулярные решения, на которые вы сами не можете повлиять.
И делать это так, чтобы люди поняли.
Итог.
Сейчас понял, что пункты выше — это только про взаимодействие с людьми.
А еще есть:
— заказчики, которые меняют требования на ходу
— подрядчики, которые нарушают обещания
— руководство, которое спускает сверху занимательные упражнения, логику и смысл которых уже никто не понимает
— инциденты
— горящие проекты
— бюрократия, эксельки, отчетность, сертификация, ...
Тимлид — это не задачки раздавать и в носу ковырять.
Тимлид — это проблемки решать и своей жопой отвечать за чужие косяки.
10 раз подумайте, какое соотношение приятной и неприятной работы вас будет устраивать.
Все знают, что быть тимлидом — это примерно так:
— Сидишь в кресле
— Двигаешь задачки по доске
— Говоришь людям, что делать
— Иногда мудро смотришь в окно
— Шутишь несмешные шутки и над ними всё равно смеются
Потом тебя повышают до CTO, потому что ты хорошо двигал задачки.
Хрен там.
Большая часть работы тимлида — это работать с неприятными вещами, которые раньше проходили где-то рядом, а теперь стали твоей проблемой.
По моим наблюдениям, у многих ребят при переходе из разработчика в тимлида резко меняется процентное соотношение приятной и неприятной работы.
Условно, было 80%/20% , а стало 30%/70%. Ниже соберу часть неприятностей работы тимлида, чтобы вы могли подумать, а надо ли вам оно.
📌 Нужно
Люди косячат и тебе нужно давать обратную связь.
Не булшит-бургер «ты молодец, но вот тут надо получше», а конкретно:
«Вот здесь работа сделана плохо. Вот факты. Вот последствия. Вот что нужно изменить».
Человеку неприятно.
Тебе тоже неприятно.
Если вы получаете корректирующий фидбек от руководителя — знайте, ему эта часть работы не доставляет удовольствия. Ну только если не человек с отклонениями, но предположим что орущего социопата вы сможете отличить и послать нахер.
📌 Люди ошибаются
Иногда ты видишь, что человек собирается наступить на грабли.
И тебе нужно не побежать всё чинить, а дать ему ошибиться, чтобы он научился.
А потом помочь разгрести последствия, потому что отвечать за результат всё равно тебе.
Сложность в том, что чем выше грейд сотрудника, тем больнее обычно грабли и более долгосрочные последствия ошибки.
— Ошибка стажера фиксится в течение дня. Передаю привет всем менторам стажеров, которым сложно дать человеку ошибиться, потому что «надо всё сделать нормально с первого раза».
— Ошибка сеньора — квартал+. И тут тимлиду уже реально важно уметь отличить критичную проблему от минорной.
— Ошибка тимлида проявляется только через 9 месяцев, и еще поди осознай, что это вот то принятое 9 месяцев назад решение. Проблема в том, что тимлидов обычно никто не спасает от хождения по граблям 😅 И никто не помогает простроить цепочку поиска руткоза / ошибочного решения. В этом плане обучение тимлида — дело рук самого тимлида.
📌 Люди чего-то хотят, но не всегда понимают зачем
— Хочу расти.
— Окей, а зачем?
— Ну Вася вырос.
— Окей, а тебе зачем?
— Ну… надо.
Пу-пу-пу.
И дальше ты пытаешься понять, это денежная мотивация, желание лычки, или просто человеку скучно.
И вот ты уже персональный психолог и коуч — помогаешь сотруднику понять, чего же он хочет.
📌 Люди ноют
У каждого есть проблемы, тревоги, конфликты, ожидания, усталость, ипотека, собака, переезд, сложный проект, непонятный продукт, плохое настроение и ощущение, что всё бессмысленно.
Когда ты внутри команды, ты видишь только свою боль.
Когда ты тимлид, у тебя в голове девять чужих болей. Ты не должен быть психологом для каждого, но должен поддерживать доверительные отношения и уметь «оказать первую помощь».
Такое вот насильное расширение сознания.
📌 Людей иногда приходится увольнять
Не в первый месяц.
Может быть, не в первый год.
Но если вы идёте в менеджмент, надо понимать: когда-нибудь придётся.
Или увольнять, или сокращать, или объяснять непопулярные решения, на которые вы сами не можете повлиять.
И делать это так, чтобы люди поняли.
Итог.
Сейчас понял, что пункты выше — это только про взаимодействие с людьми.
А еще есть:
— заказчики, которые меняют требования на ходу
— подрядчики, которые нарушают обещания
— руководство, которое спускает сверху занимательные упражнения, логику и смысл которых уже никто не понимает
— инциденты
— горящие проекты
— бюрократия, эксельки, отчетность, сертификация, ...
Тимлид — это не задачки раздавать и в носу ковырять.
Тимлид — это проблемки решать и своей жопой отвечать за чужие косяки.
10 раз подумайте, какое соотношение приятной и неприятной работы вас будет устраивать.
❤62💯43👍17🔥4🤩1🐳1
Личный бренд не двигает карьеру
Веду этот канал пять лет. Что он мне реально принёс: знакомства, пару подкастов, рефлексию во время написания постов и донесение мыслей до коллег. Еще иногда (очень редко) консалтинг / менторинг. А, и возможность поныть сразу на тысячу человек, конечно же.
Но для карьеры внутри своей же компании он не дал ничего. Хотя по логике интернета должно быть наоборот: блог = успешный успех.
По моему опыту, перформанс на работе и ведение канала — это два параллельных трека. И один про другой не говорит вообще ничего.
Бывает, человек и посты годные пишет, и работу работает. Отлично, вопросов нет.
А бывает наоборот.
Читаешь канал — умнейший человек, всё по полочкам.
Потом взаимодействуешь по работе, — и не веришь, что это один и тот же человек.
Так что блог — вообще не сигнал о том, какой ты в работе.
Больше скажу: на найме он мне скорее мешал. Когда переходил в Райф, ребята из команды потом честно признались — была мыслишка в духе «о, блогер пришёл, сейчас будет не работу работать, а канал свой вести». Жёлтый флаг, короче.
А, и про «с блогом тебя начнут хантить»: за пять лет — ни одного оффера в личку. Ноль.
Повышение внутри компании тоже идёт совсем по другой логике.
Делаешь работу следующего грейда, закрываешь матрицу компетенций, руководитель и окружающие это видят.
Личного бренда обычно в матрице компетенций нет.
При этом блог не бесполезен. Просто польза у него другая, наружу. Кому он правда нужен как рычаг — тем, кто продаёт себя вовне: консалтинг, курсы, найм через свой блог, фаундерство, прыжки по компаниям раз в год. Там личный бренд иногда вообще единственный двигатель. А если ты растёшь внутри корпы по грейдам — это приятное хобби, и не надо себе врать, что оно про карьеру.
И да, я прекрасно понимаю, что пишу всё это в своём же личном блоге. Ну а где ещё ныть на тысячу человек.
———
Что еще принёс этот канал — мне выпала честь выступить с ув. тов. Орловым и Панкратовым 25 июня.
Будем вживую собирать тир-лист карьерных навыков: что реально тащит наверх, а что только кажется. Спойлер: личный бренд там сядет куда ниже, чем все привыкли думать. Этот пост — по сути разбор одной клетки той доски; на эфире разложим всю и поспорим.
Про мероприятие. Это бесплатный управленческий онлайн-кэмп от Стратоплана.
📅 22–25 июня, 18:00–21:00 МСК, по вечерам
4 дня:
1. Для оунеров, СЕО и C-lvl
2. Для тимлидов и руководителей отделов
3. Для технических и операционных директоров
4. Для тех, кто думает о карьерном развитии — я буду здесь.
💸 бесплатно — нужна подписка на каналы. Есть платный вариант без подписок, плюс бонусом запись закрытой программы «Руководитель 2030»
🔗 на выходе сертификат, можно повесить в LinkedIn
Регистрация: https://stratoplan-school.com/camp/pdev/
Веду этот канал пять лет. Что он мне реально принёс: знакомства, пару подкастов, рефлексию во время написания постов и донесение мыслей до коллег. Еще иногда (очень редко) консалтинг / менторинг. А, и возможность поныть сразу на тысячу человек, конечно же.
Но для карьеры внутри своей же компании он не дал ничего. Хотя по логике интернета должно быть наоборот: блог = успешный успех.
По моему опыту, перформанс на работе и ведение канала — это два параллельных трека. И один про другой не говорит вообще ничего.
Бывает, человек и посты годные пишет, и работу работает. Отлично, вопросов нет.
А бывает наоборот.
Читаешь канал — умнейший человек, всё по полочкам.
Потом взаимодействуешь по работе, — и не веришь, что это один и тот же человек.
Так что блог — вообще не сигнал о том, какой ты в работе.
Больше скажу: на найме он мне скорее мешал. Когда переходил в Райф, ребята из команды потом честно признались — была мыслишка в духе «о, блогер пришёл, сейчас будет не работу работать, а канал свой вести». Жёлтый флаг, короче.
А, и про «с блогом тебя начнут хантить»: за пять лет — ни одного оффера в личку. Ноль.
Повышение внутри компании тоже идёт совсем по другой логике.
Делаешь работу следующего грейда, закрываешь матрицу компетенций, руководитель и окружающие это видят.
Личного бренда обычно в матрице компетенций нет.
При этом блог не бесполезен. Просто польза у него другая, наружу. Кому он правда нужен как рычаг — тем, кто продаёт себя вовне: консалтинг, курсы, найм через свой блог, фаундерство, прыжки по компаниям раз в год. Там личный бренд иногда вообще единственный двигатель. А если ты растёшь внутри корпы по грейдам — это приятное хобби, и не надо себе врать, что оно про карьеру.
И да, я прекрасно понимаю, что пишу всё это в своём же личном блоге. Ну а где ещё ныть на тысячу человек.
———
Что еще принёс этот канал — мне выпала честь выступить с ув. тов. Орловым и Панкратовым 25 июня.
Будем вживую собирать тир-лист карьерных навыков: что реально тащит наверх, а что только кажется. Спойлер: личный бренд там сядет куда ниже, чем все привыкли думать. Этот пост — по сути разбор одной клетки той доски; на эфире разложим всю и поспорим.
Про мероприятие. Это бесплатный управленческий онлайн-кэмп от Стратоплана.
📅 22–25 июня, 18:00–21:00 МСК, по вечерам
4 дня:
1. Для оунеров, СЕО и C-lvl
2. Для тимлидов и руководителей отделов
3. Для технических и операционных директоров
4. Для тех, кто думает о карьерном развитии — я буду здесь.
💸 бесплатно — нужна подписка на каналы. Есть платный вариант без подписок, плюс бонусом запись закрытой программы «Руководитель 2030»
🔗 на выходе сертификат, можно повесить в LinkedIn
Регистрация: https://stratoplan-school.com/camp/pdev/
❤37👍34🔥15
Промо зависит от руководителя
Как бы хорошо ни была выстроена система перформанс-ревью в компании, на промо вас всё равно ведет руководитель. Можно сколько угодно закрывать матрицу компетенций, но без него ничего не случится.
В прошлом посте была фраза: руководитель, мол, «это видит». Так вот: сам по себе он ни хрена не видит.
(Антон, если ты вдруг это читаешь — это не про тебя, это другой, абстрактный руководитель 😅)
Распишу несколько конкретных принципов стейкхолдер-менеджмента руководителя из моего опыта.
Работать по Push-модели, а не Pull.
Проще всего объяснить разницу на примере 1-1. Главная мысль: встречу ведет тот, кто задает вопросы. Вы должны вести ваши 1-1 с руководителем.
Если он задает вам вопросы — он вытягивает из вас информацию. Это Pull.
Нужно самому пушить в руководителя информацию: сам приносишь повестку, сам рассказываешь, что происходит, сам пишешь фолоу-апы после 1-1, сам назначаешь на себя экшен-айтемы, сам их закрываешь. Это Push.
Почему pull это плохо.
1. На 1-1 всплывает только то, о чем руководитель догадался спросить. Половина твоей работы остаётся за кадром.
2. Создается привычка, что тебя надо контролировать. Нет простора для роста кредита доверия.
3. Нет возможности показать, что ты самостоятельный и можешь закрывать экстра-скоуп, о котором руководитель мог даже не знать.
Обеспечивать прозрачность.
Хочется быть для руководителя чёрным ящиком: «всё хорошо, всё хорошо, проблема решена, всё хорошо». Кажется, это вершина доверия — он тебе верит и не лезет. Но в матрице доверие/прозрачность это самый хрупкий квадрант: высокое доверие без прозрачности держится до первой проблемы.
Стратоплановская классика. Чем хуже дела, тем чаще про них рассказывай. «Вот проблема, так планирую решать, вот альтернативы, которые посмотрел. Хочешь поправить — скажи. Если нет — отчитаюсь, когда закрою».
Руководитель спокоен, ты автономен, доверие растёт.
Соблюдать договорённости.
Взял срок — держи. Видишь, что не успеваешь, — подсвети заранее и объясни почему. Решил, что важнее потушить другой пожар, — скажи об этом прямо. Один молча просранный коммит стоит дороже трёх честно передоговорённых.
Согласовывать ожидания.
Базово — быть выровненным с руководителем, что он считает хорошим результатом. Если идешь в промо — что нужно сделать для этого.
Руководитель — человек занятой. Можно до пенсии ждать, пока он сам распишет, что нужно для следующего грейда. Поэтому критерии я выписал сам. Скинул ему, он подсветил, что подправить, утвердили. И дальше я пошёл копать. Копал девять месяцев. Как докопал — промо прошло гладко и с первого раза.
... to be continued 🙂
———
Завтра, 25 июня, про это поговорим вживую. На эфире собираем тир-лист карьерных навыков, и «работа с руководителем» у меня едет в самый верх доски — без неё всё остальное в рост не конвертируется. Сегодняшний пост — одна клетка той доски; завтра увидите всю и поспорим.
📅 25 июня, 18:00–21:00 МСК — день для тех, кто думает про карьерное развитие, я там
💸 бесплатно (нужна подписка на каналы); есть платный вариант без подписок + бонусом запись «Руководитель 2030»
🔗 на выходе сертификат, можно повесить в LinkedIn
Регистрация: https://stratoplan-school.com/camp/pdev/
P.S. А у вас 1-1 кто ведёт — вы или руководитель?
Как бы хорошо ни была выстроена система перформанс-ревью в компании, на промо вас всё равно ведет руководитель. Можно сколько угодно закрывать матрицу компетенций, но без него ничего не случится.
В прошлом посте была фраза: руководитель, мол, «это видит». Так вот: сам по себе он ни хрена не видит.
(Антон, если ты вдруг это читаешь — это не про тебя, это другой, абстрактный руководитель 😅)
Распишу несколько конкретных принципов стейкхолдер-менеджмента руководителя из моего опыта.
Работать по Push-модели, а не Pull.
Проще всего объяснить разницу на примере 1-1. Главная мысль: встречу ведет тот, кто задает вопросы. Вы должны вести ваши 1-1 с руководителем.
Если он задает вам вопросы — он вытягивает из вас информацию. Это Pull.
Нужно самому пушить в руководителя информацию: сам приносишь повестку, сам рассказываешь, что происходит, сам пишешь фолоу-апы после 1-1, сам назначаешь на себя экшен-айтемы, сам их закрываешь. Это Push.
Почему pull это плохо.
1. На 1-1 всплывает только то, о чем руководитель догадался спросить. Половина твоей работы остаётся за кадром.
2. Создается привычка, что тебя надо контролировать. Нет простора для роста кредита доверия.
3. Нет возможности показать, что ты самостоятельный и можешь закрывать экстра-скоуп, о котором руководитель мог даже не знать.
Обеспечивать прозрачность.
Хочется быть для руководителя чёрным ящиком: «всё хорошо, всё хорошо, проблема решена, всё хорошо». Кажется, это вершина доверия — он тебе верит и не лезет. Но в матрице доверие/прозрачность это самый хрупкий квадрант: высокое доверие без прозрачности держится до первой проблемы.
Стратоплановская классика. Чем хуже дела, тем чаще про них рассказывай. «Вот проблема, так планирую решать, вот альтернативы, которые посмотрел. Хочешь поправить — скажи. Если нет — отчитаюсь, когда закрою».
Руководитель спокоен, ты автономен, доверие растёт.
Соблюдать договорённости.
Взял срок — держи. Видишь, что не успеваешь, — подсвети заранее и объясни почему. Решил, что важнее потушить другой пожар, — скажи об этом прямо. Один молча просранный коммит стоит дороже трёх честно передоговорённых.
Согласовывать ожидания.
Базово — быть выровненным с руководителем, что он считает хорошим результатом. Если идешь в промо — что нужно сделать для этого.
Руководитель — человек занятой. Можно до пенсии ждать, пока он сам распишет, что нужно для следующего грейда. Поэтому критерии я выписал сам. Скинул ему, он подсветил, что подправить, утвердили. И дальше я пошёл копать. Копал девять месяцев. Как докопал — промо прошло гладко и с первого раза.
... to be continued 🙂
———
Завтра, 25 июня, про это поговорим вживую. На эфире собираем тир-лист карьерных навыков, и «работа с руководителем» у меня едет в самый верх доски — без неё всё остальное в рост не конвертируется. Сегодняшний пост — одна клетка той доски; завтра увидите всю и поспорим.
📅 25 июня, 18:00–21:00 МСК — день для тех, кто думает про карьерное развитие, я там
💸 бесплатно (нужна подписка на каналы); есть платный вариант без подписок + бонусом запись «Руководитель 2030»
🔗 на выходе сертификат, можно повесить в LinkedIn
Регистрация: https://stratoplan-school.com/camp/pdev/
P.S. А у вас 1-1 кто ведёт — вы или руководитель?
👍37🔥25❤5👎1
С этими вашими AI агентами мы снова попали на дикий запад
Момент времени Т-4: Когда-то давно для нового разработчика в компании выделялось несколько дней, а то и недель, чтобы настроить под себя рабочее окружение. Начиная от настройки ОС, и заканчивая выбором веб-сервера и установкой базы данных. А потом связкой этого всего друг с другом. Представляете: люди отдельно ставили себе Apache и MySQL, руками перекладывали PHP-исходники в директорию апача, руками правили конфиги чтобы правильный порт MySQL прописать. На разворачивание среды разработки для новых сотрудников закладывали неделю-две.
Момент времени Т-3: Появляются стандарты. LAMP, XAMPP, Denwer, ... Онбординг нового программиста теперь занимает 1 день.
Момент времени Т-2: Все инструменты разработки стандартизированы, есть платформы, есть облака, на практически любой вопрос есть ответ.
Момент времени Т-1: С появлением кодящих агентов мы откатились к этапу Т-4: "каждый колбасит сам как умеет, делимся экспертизой, ищем сценарии применения и лучшие практики".
Момент времени Т-0 (Сейчас): Мы на этапе, когда уже набралось определенное количество сценариев применения и лучших практик. При этом с точки зрения стандартизации мы всё еще в древних временах, когда еще даже не появились LAMP и Денвер.
Образ будущего Т+1: Верю, что появятся стандарты использования кодящих агентов. Может быть, на уровне промптов для самих агентов.
Чтобы агент подсказывал оператору (разработчику), как его правильно использовать.
- Скиллы, mcp, подходы.
- Запускать brainstorm -> writing-plans -> subagents-flow -> finish-branch-development
- Делать регулярный Handoff и compact
- Писать по TDD или даже TBD.
- Избегать откладывания техдолга.
- Следовать правилу бойскаута (оставлять поляну чуть чище чем была до прихода). Дробить на атомарные пулл реквесты.
Проще всего это сделать с помощью AGENTS.md в корне проекта (+симлинкать на него CLAUDE.md)
Верю, что уменьшится метрика Rework. Возможно, что-то еще.
Впрочем, AGENTS.md — это такой же простой совет, уровня шаринга экспертизы.
Видимо, образ будущего я пока не вижу. Впрочем, не я один.
Поэтому остаемся в моменте времени Т+0 и делимся экспертизой.
———
Собственно, почему я пишу этот пост.
Мой давний товарищ Егор Толстой из Подлодки запустил закрытое сообщество инженеров, которые уже активно используют AI в работе и хотят делать это системно.
Концепт клуба:
1. Берем эксперта из Uber, xAI, Meta, Яндекса, Cursor, ...
2. Проводим стрим. Уже прошло больше 40 стримов на разные темы — фреймворки, Spec-Driven Development, общий реестр скиллов для команды, автономные фабрики фичей, ...
3. Обсуждаем в чате. Расходимся по комнатам на разные темы — локальные модели, SDD, ...
4. Бот как база знаний на основе всего архива прошедших стримов и обсуждений в чате
5. Хакатоны! сдедующий в августе, на тему самообучающихся агентов и долгосрочной памяти.
Если вы уже активно внедряете AI в свою работу или команды — сможете найти единомышленников с похожими проблемами. Как работать со скептиками, как не попасть в зависимость от вендоров моделей, как не сжечь все бюджеты на токены – можно обсуждать в чате и на Random Coffee.
🔗Детали, расписание, заявки в клуб
Био-Органический текст. Написан без применения AI.
Момент времени Т-4: Когда-то давно для нового разработчика в компании выделялось несколько дней, а то и недель, чтобы настроить под себя рабочее окружение. Начиная от настройки ОС, и заканчивая выбором веб-сервера и установкой базы данных. А потом связкой этого всего друг с другом. Представляете: люди отдельно ставили себе Apache и MySQL, руками перекладывали PHP-исходники в директорию апача, руками правили конфиги чтобы правильный порт MySQL прописать. На разворачивание среды разработки для новых сотрудников закладывали неделю-две.
Момент времени Т-3: Появляются стандарты. LAMP, XAMPP, Denwer, ... Онбординг нового программиста теперь занимает 1 день.
Момент времени Т-2: Все инструменты разработки стандартизированы, есть платформы, есть облака, на практически любой вопрос есть ответ.
Момент времени Т-1: С появлением кодящих агентов мы откатились к этапу Т-4: "каждый колбасит сам как умеет, делимся экспертизой, ищем сценарии применения и лучшие практики".
Момент времени Т-0 (Сейчас): Мы на этапе, когда уже набралось определенное количество сценариев применения и лучших практик. При этом с точки зрения стандартизации мы всё еще в древних временах, когда еще даже не появились LAMP и Денвер.
Образ будущего Т+1: Верю, что появятся стандарты использования кодящих агентов. Может быть, на уровне промптов для самих агентов.
Чтобы агент подсказывал оператору (разработчику), как его правильно использовать.
- Скиллы, mcp, подходы.
- Запускать brainstorm -> writing-plans -> subagents-flow -> finish-branch-development
- Делать регулярный Handoff и compact
- Писать по TDD или даже TBD.
- Избегать откладывания техдолга.
- Следовать правилу бойскаута (оставлять поляну чуть чище чем была до прихода). Дробить на атомарные пулл реквесты.
Проще всего это сделать с помощью AGENTS.md в корне проекта (+симлинкать на него CLAUDE.md)
Верю, что уменьшится метрика Rework. Возможно, что-то еще.
Впрочем, AGENTS.md — это такой же простой совет, уровня шаринга экспертизы.
Видимо, образ будущего я пока не вижу. Впрочем, не я один.
Поэтому остаемся в моменте времени Т+0 и делимся экспертизой.
———
Собственно, почему я пишу этот пост.
Мой давний товарищ Егор Толстой из Подлодки запустил закрытое сообщество инженеров, которые уже активно используют AI в работе и хотят делать это системно.
Концепт клуба:
1. Берем эксперта из Uber, xAI, Meta, Яндекса, Cursor, ...
2. Проводим стрим. Уже прошло больше 40 стримов на разные темы — фреймворки, Spec-Driven Development, общий реестр скиллов для команды, автономные фабрики фичей, ...
3. Обсуждаем в чате. Расходимся по комнатам на разные темы — локальные модели, SDD, ...
4. Бот как база знаний на основе всего архива прошедших стримов и обсуждений в чате
5. Хакатоны! сдедующий в августе, на тему самообучающихся агентов и долгосрочной памяти.
Если вы уже активно внедряете AI в свою работу или команды — сможете найти единомышленников с похожими проблемами. Как работать со скептиками, как не попасть в зависимость от вендоров моделей, как не сжечь все бюджеты на токены – можно обсуждать в чате и на Random Coffee.
🔗Детали, расписание, заявки в клуб
Био-Органический текст. Написан без применения AI.
Podlodka AI Engineers Club
Учимся применять AI и внедрять его в команды. Еженедельные сессии с экспертами и живое сообщество от создателей подкаста Подлодка.
👍13❤5🐳5👎3🤣2
Доставка смс в самолёт
Сижу в самолёте. С интернетом, что само по себе — чудо, которое уже пару раз использовал, но каждый раз удивляюсь.
Хочу залогиниться на какой-то сайт по номеру телефона.
Ввожу номер, потом думаю: блин, мобильной-то сети нет.
Проходит секунд 20 — в правом верхнем углу макбука всплывашка: пришло сообщение, код 1234.
Думаю: нихрена себе. Мне доставили SMS от банка на высоте 10 км над Средиземным морем, без единой сотовой вышки. Как?
По Voice over WiFi.
При чем WiFi Calling я раньше использовал. Иногда приходится голосом разруливать всякое с российскими банками, госуслугами, поддержками. В Испании это конский роуминг за минуту. Но с WiFi Calling — по тарифу домашнего региона. Очень полезно для эмигрантов и тех, кто много мотается.
Но раньше я не задумывался, что и смски ходят так же по WiFi.
Полез разбираться, как это устроено. Вот, вам приношу.
———
Как это работает:
1. Телефон коннектится к любому wifi — хоть к домашнему, хоть к кафешному или офисному.
2. Через DNS находит адрес шлюза оператора. Шлюз называется ePDG — по сути VPN-концентратор, специальный вход в сеть оператора для «недоверенных» сетей. Любой wifi для оператора недоверенный, потому что не он им управляет.
3. Телефон поднимает до этого шлюза зашифрованный IPsec-тоннель (по IKEv2). Дальше все звонки и SMS едут внутри этой шифрованной трубы. Соседу по кафешному wifi виден только зашифрованный поток.
4. Через тоннель телефон регистрируется в IMS — это контроллер оператора, который рулит звонками и SMS. Он же обслуживает VoLTE (звонки поверх LTE). То есть WiFi Calling и VoLTE — близнецы, отличается только последняя миля: там радио, тут wifi.
5. Телефон проходит аутентификацию симкой по протоколу EAP-AKA. Секретный ключ с симки наружу вообще не уходит. Оператор присылает challenge, симка решает её внутри себя своим ключом и возвращает ответ. Совпало — пустили. Те же секреты, что подтверждают тебя на вышке, теперь работают через обычный интернет, но сам ключ по проводам не светится.
Поэтому это твой настоящий номер, а не приложение и не отдельный аккаунт.
6. Для SMS есть спец-адаптер: IP-SM-GW. Старая система рассылки SMSC умеет говорить только на языке классических сотовых сетей и не знает, что такое wifi. Переходник берёт у неё SMS и переупаковывает в формат IMS, чтобы доставить по тоннелю. Причём он прикидывается твоим телефоном — поэтому старая система не парится, где ты физически. Ей подсунули адрес адаптера — она доставила.
На регистрацию в VoWiFi уходит время: найти шлюз, поднять тоннель, доказать симкой, кто ты такой, зарегистрироваться.
Из проблем:
1. Раз мозг общий с VoLTE, по идее звонок должен бесшовно переезжать между wifi и сотовой. На бумаге так и написано. У меня — ни разу. По мере отхода от роутера сигнал wifi тупо деградирует, звук начинает сыпаться, и до переключения на сотовую оно нормально не доживает — звонок скорее оборвётся, чем «бесшовно переедет».
2. Если WiFi Calling «не включается», частая причина — фаервол режет нужные порты (UDP 500 и 4500 плюс протокол ESP). Тогда оно молча падает и откатывается на сотовую.
Прикольно, что систему построили поверх готовой инфры: симка с ключом, IMS контроллер, рассыльщику SMS подсунули адаптер.
Подробная статья про последовательность установки соединения — для тех, кто хочет углубиться.
———
В чудесное время живём: интернет в самолете, смска по WiFi, и автоподстановка кода из смс с айфона на макбуке.
А у вас WiFi Calling включен?
Сижу в самолёте. С интернетом, что само по себе — чудо, которое уже пару раз использовал, но каждый раз удивляюсь.
Хочу залогиниться на какой-то сайт по номеру телефона.
Ввожу номер, потом думаю: блин, мобильной-то сети нет.
Проходит секунд 20 — в правом верхнем углу макбука всплывашка: пришло сообщение, код 1234.
Думаю: нихрена себе. Мне доставили SMS от банка на высоте 10 км над Средиземным морем, без единой сотовой вышки. Как?
По Voice over WiFi.
При чем WiFi Calling я раньше использовал. Иногда приходится голосом разруливать всякое с российскими банками, госуслугами, поддержками. В Испании это конский роуминг за минуту. Но с WiFi Calling — по тарифу домашнего региона. Очень полезно для эмигрантов и тех, кто много мотается.
Но раньше я не задумывался, что и смски ходят так же по WiFi.
Полез разбираться, как это устроено. Вот, вам приношу.
———
Как это работает:
1. Телефон коннектится к любому wifi — хоть к домашнему, хоть к кафешному или офисному.
2. Через DNS находит адрес шлюза оператора. Шлюз называется ePDG — по сути VPN-концентратор, специальный вход в сеть оператора для «недоверенных» сетей. Любой wifi для оператора недоверенный, потому что не он им управляет.
3. Телефон поднимает до этого шлюза зашифрованный IPsec-тоннель (по IKEv2). Дальше все звонки и SMS едут внутри этой шифрованной трубы. Соседу по кафешному wifi виден только зашифрованный поток.
4. Через тоннель телефон регистрируется в IMS — это контроллер оператора, который рулит звонками и SMS. Он же обслуживает VoLTE (звонки поверх LTE). То есть WiFi Calling и VoLTE — близнецы, отличается только последняя миля: там радио, тут wifi.
5. Телефон проходит аутентификацию симкой по протоколу EAP-AKA. Секретный ключ с симки наружу вообще не уходит. Оператор присылает challenge, симка решает её внутри себя своим ключом и возвращает ответ. Совпало — пустили. Те же секреты, что подтверждают тебя на вышке, теперь работают через обычный интернет, но сам ключ по проводам не светится.
Поэтому это твой настоящий номер, а не приложение и не отдельный аккаунт.
6. Для SMS есть спец-адаптер: IP-SM-GW. Старая система рассылки SMSC умеет говорить только на языке классических сотовых сетей и не знает, что такое wifi. Переходник берёт у неё SMS и переупаковывает в формат IMS, чтобы доставить по тоннелю. Причём он прикидывается твоим телефоном — поэтому старая система не парится, где ты физически. Ей подсунули адрес адаптера — она доставила.
На регистрацию в VoWiFi уходит время: найти шлюз, поднять тоннель, доказать симкой, кто ты такой, зарегистрироваться.
Из проблем:
1. Раз мозг общий с VoLTE, по идее звонок должен бесшовно переезжать между wifi и сотовой. На бумаге так и написано. У меня — ни разу. По мере отхода от роутера сигнал wifi тупо деградирует, звук начинает сыпаться, и до переключения на сотовую оно нормально не доживает — звонок скорее оборвётся, чем «бесшовно переедет».
2. Если WiFi Calling «не включается», частая причина — фаервол режет нужные порты (UDP 500 и 4500 плюс протокол ESP). Тогда оно молча падает и откатывается на сотовую.
Прикольно, что систему построили поверх готовой инфры: симка с ключом, IMS контроллер, рассыльщику SMS подсунули адаптер.
Подробная статья про последовательность установки соединения — для тех, кто хочет углубиться.
———
В чудесное время живём: интернет в самолете, смска по WiFi, и автоподстановка кода из смс с айфона на макбуке.
А у вас WiFi Calling включен?
👍24🔥19❤10🤩1
AI-агенты — это ответ! А какой был ваш вопрос?
Все бегут в разработку через AI.
Во-первых, это прикольно.
Во-вторых, это ускоряет!
Да? А как вы это поняли? Больше строк кода в минуту?
Законтрибьютил в liquibase, пофиксил проблемку которую пришлось обходить 6 лет назад, когда еще активно кодил.
Код написал за вечер.
Замержили спустя полтора месяца. Потом еще спустя месяц пофиксили багу, которую мы с клодом породили.
Ускорил ли клод разработку? Да, я быстро написал код. Предыдущие 6 лет руки не доходили.
Но в итоге всё равно изменение доехало до прода через 1.5 месяца. А потом еще потратили время на починку баги.
Почему так?
Мы просто перенесли ботлнек на следующий этап.
Программисты и так не любили ревьювить, а теперь мы им подсовываеем огроменные PR на десять тыщ строк, с кучей лишних комментов и спорным кодом.
При прочтении нейрослопа меня самого аж выворачивает: автор потратил собственного времени меньше, чем я потрачу на чтение. И нахрен оно мне?
Попробуйте измерить cycle time по задачам. Удивитесь, но вполне вероятно, что ускорения не увидите, потому что задачи застревают на более поздних этапах.
А дальше вопрос: как ускорять ревью. И надо ли?
Или может быть надо отменить ревью человеками и доверить ревью агентам?
И обмазать это всё quality gate’ами.
Но Неет! Нельзя без ревью! Если не делать ревью, то агенты выпускают сразу легаси. Легаси — это по определению код, в котором никто не разбирается.
Но в чем отличие от вашего текущего легаси?
В любом случае такого кода у вас 95%. А если это не так сейчас, то станет так через несколько лет: новые фичи пишутся, старый код выветривается из головы, разработчики меняются.
Остается только дока.
Так что с появлением LLM-сгенерированного кода ситуация не ухудшится.
А ошибаются все: и кожаные, и агенты. Просто у нас толерантность к ошибкам железных сильно ниже.
Потому что боимся, что они нас заменят, и поэтому всячески ищем, чем они плохи.
В этом посте вопросов больше чем ответов, потому что у меня самого их нет. Давайте порассуждаем.
На сколько у вас увеличилась скорость разработки?
Делаете кодревью сгенерированного кода?
Если нет, то какие доп меры обеспечения качества внедрили?
Все бегут в разработку через AI.
Во-первых, это прикольно.
Во-вторых, это ускоряет!
Да? А как вы это поняли? Больше строк кода в минуту?
Законтрибьютил в liquibase, пофиксил проблемку которую пришлось обходить 6 лет назад, когда еще активно кодил.
Код написал за вечер.
Замержили спустя полтора месяца. Потом еще спустя месяц пофиксили багу, которую мы с клодом породили.
Ускорил ли клод разработку? Да, я быстро написал код. Предыдущие 6 лет руки не доходили.
Но в итоге всё равно изменение доехало до прода через 1.5 месяца. А потом еще потратили время на починку баги.
Почему так?
Мы просто перенесли ботлнек на следующий этап.
Программисты и так не любили ревьювить, а теперь мы им подсовываеем огроменные PR на десять тыщ строк, с кучей лишних комментов и спорным кодом.
При прочтении нейрослопа меня самого аж выворачивает: автор потратил собственного времени меньше, чем я потрачу на чтение. И нахрен оно мне?
Попробуйте измерить cycle time по задачам. Удивитесь, но вполне вероятно, что ускорения не увидите, потому что задачи застревают на более поздних этапах.
А дальше вопрос: как ускорять ревью. И надо ли?
Или может быть надо отменить ревью человеками и доверить ревью агентам?
И обмазать это всё quality gate’ами.
Но Неет! Нельзя без ревью! Если не делать ревью, то агенты выпускают сразу легаси. Легаси — это по определению код, в котором никто не разбирается.
Но в чем отличие от вашего текущего легаси?
В любом случае такого кода у вас 95%. А если это не так сейчас, то станет так через несколько лет: новые фичи пишутся, старый код выветривается из головы, разработчики меняются.
Остается только дока.
Так что с появлением LLM-сгенерированного кода ситуация не ухудшится.
А ошибаются все: и кожаные, и агенты. Просто у нас толерантность к ошибкам железных сильно ниже.
Потому что боимся, что они нас заменят, и поэтому всячески ищем, чем они плохи.
В этом посте вопросов больше чем ответов, потому что у меня самого их нет. Давайте порассуждаем.
На сколько у вас увеличилась скорость разработки?
Делаете кодревью сгенерированного кода?
Если нет, то какие доп меры обеспечения качества внедрили?
GitHub
fix(postgres): preserve PARTITION BY in diff-changelog (#6885) by Khromushkin · Pull Request #7759 · liquibase/liquibase
Impact
Bug fix (non-breaking change which fixes expected existing functionality)
Enhancement/New feature (adds functionality without impacting existing logic)
Breaking change
Description
Postg...
Bug fix (non-breaking change which fixes expected existing functionality)
Enhancement/New feature (adds functionality without impacting existing logic)
Breaking change
Description
Postg...
👍19💯11❤2
Avito.Tech.Conf — 26 сентября, Москва, бесплатно
Бесплатных конференций вам в ленту! Спикеры — мои коллеги, так что рекомендую с чистой совестью.
Avito.Tech.Conf — для тех, кто управляет продуктами, процессами и командами. Один день, главная сцена плюс зал воркшопов, 12 спикеров, панель с СТО Яндекс Карт, Х5, Т-Банка и Циана. После 18:30 афтепати.
Программа на лендосе. Что бы я пошёл слушать:
1️⃣ — Александр Лукьянченко, СТО Tech Platform Авито. Как меняется разработка и сетап команд с внедрением агентов
Keynote про то, как измерять эффект от AI и где он создаёт новые узкие места. У меня по этой теме вопросов больше, чем ответов, так что очень интересно будет поразмышлять вместе.
2️⃣ — Артём Арюткин, Developer Experience Авито. Как реально меняется PDLC, или почему вы ускоряете не то, что нужно
См мой прошлый пост: Код пишется за вечер, до прода едет месяц.
3️⃣ — Михаил Павлов, кластер Infrastructure. Повышать планку, не превращаясь в «эффективного менеджера»
Про личные триггеры: бесконечные итерации в гуглодоках и попытки спрятаться за инструментами, когда надо принять решение. Узнал себя еще по описанию.
4️⃣ — Александр Афенов, кластер Доставка. Нам и так было норм: антипаттерны реоргов
Саша — мой коллега, я уже зазывал вас на его доклад про Жоку и Боку. А я за прошлый год провел три реорга, так что тема в сердечке.
Из воркшопов — Tech Strategy Canvas от Игоря Гранщикова. Свою стратегию кластера я писал 4 месяца, и в процессе мне очень помог фреймворк Игоря. Хочу посмотреть, как это собирают за полтора часа.
Еще будут мастермайнды, 1-1 с руководителями разработки Авито по записи и зоны вертикалей: покер-клуб с управленческими дилеммами, гараж с «техосмотром» руководителя, розыгрыш вещей с Авито в стиле «Угадай цену», бильярд и кальян.
26 сентября, AG Loft (Варшавское шоссе, 33), Москва. Сбор с 11:00, доклады с 12:00.
Участие бесплатное.
Оффлайн — по заявке, мест немного.
Онлайн — регистрация, пришлют трансляцию и записи.
Зарегистрироваться
Бесплатных конференций вам в ленту! Спикеры — мои коллеги, так что рекомендую с чистой совестью.
Avito.Tech.Conf — для тех, кто управляет продуктами, процессами и командами. Один день, главная сцена плюс зал воркшопов, 12 спикеров, панель с СТО Яндекс Карт, Х5, Т-Банка и Циана. После 18:30 афтепати.
Программа на лендосе. Что бы я пошёл слушать:
1️⃣ — Александр Лукьянченко, СТО Tech Platform Авито. Как меняется разработка и сетап команд с внедрением агентов
Keynote про то, как измерять эффект от AI и где он создаёт новые узкие места. У меня по этой теме вопросов больше, чем ответов, так что очень интересно будет поразмышлять вместе.
2️⃣ — Артём Арюткин, Developer Experience Авито. Как реально меняется PDLC, или почему вы ускоряете не то, что нужно
См мой прошлый пост: Код пишется за вечер, до прода едет месяц.
3️⃣ — Михаил Павлов, кластер Infrastructure. Повышать планку, не превращаясь в «эффективного менеджера»
Про личные триггеры: бесконечные итерации в гуглодоках и попытки спрятаться за инструментами, когда надо принять решение. Узнал себя еще по описанию.
4️⃣ — Александр Афенов, кластер Доставка. Нам и так было норм: антипаттерны реоргов
Саша — мой коллега, я уже зазывал вас на его доклад про Жоку и Боку. А я за прошлый год провел три реорга, так что тема в сердечке.
Из воркшопов — Tech Strategy Canvas от Игоря Гранщикова. Свою стратегию кластера я писал 4 месяца, и в процессе мне очень помог фреймворк Игоря. Хочу посмотреть, как это собирают за полтора часа.
Еще будут мастермайнды, 1-1 с руководителями разработки Авито по записи и зоны вертикалей: покер-клуб с управленческими дилеммами, гараж с «техосмотром» руководителя, розыгрыш вещей с Авито в стиле «Угадай цену», бильярд и кальян.
26 сентября, AG Loft (Варшавское шоссе, 33), Москва. Сбор с 11:00, доклады с 12:00.
Участие бесплатное.
Оффлайн — по заявке, мест немного.
Онлайн — регистрация, пришлют трансляцию и записи.
Зарегистрироваться
❤3🔥3🙈1
Почему AI-агенты не заменят кожаных
Disclaimer: постов будет 2, второй — «Почему заменят» 🙃
———
Давайте отмотаем.
Когда-то код писали на перфокартах. Были специально обученные люди, которые переносили программу с бумажки на картонку с дырками.
До сих пор помню, как препод по информатике рассказывала и показывала, как машины всасывали перфокарты... поднося 4 пальца правой руки ко рту и имитировала всасывающие звуки. Так, что-то я не туда ушел. Ольга Михайловна, мое почтение, надеюсь всё хорошо у вас.
Так вот. Появились терминалы с текстовыми редакторами, и первая обслуживающая программистов профессия исчезла. Программисты остались.
Потом появился Notepad++ с подсветкой синтаксиса.
Потом появились IDE. Половина продолжала писать в блокноте, потому что тормозит.
Потом появился автокомплит.
Потом IntelliSense, который дописывает строку целиком.
Потом Copilot.
Агенты — следующая ступенька.
Смотрю на это как на очень продвинутый автокомплит, который дописывает согласованный код сразу во много связанных друг с другом файлов.
Но это тула. И у тулы пока нет важнейших свойств, из-за чего она никого не заменит.
1️⃣ — У тулы нет страха смерти
Кожаный держится за рабочее место, потому что иначе будет уволен и умрёт под мостом от голода. Именно поэтому он придёт на работу утром в понедельник, доделает неприятную задачу, возьмёт трубку в три ночи и починит прод.
У агента нет ипотеки и детей. Он выключился и не вспомнит, что было.
2️⃣ — У тулы нет ответственности
— Да, я дропнул продакшен базу. Надо было сначала сделать бэкап.
(и нихрена ты мне за это не сделаешь, кожаный ублюдок)
Кого будят ночью? Кто пишет постмортем? Кого зовут к СТО объясняться?
Кожаного оператора ллм. Того, кто кнопки жмёт.
Пока ответственность на человеке, человек будет в цепочке.
———
Тула без человека не имеет применения. Молоток сам гвоздь не забьёт, даже очень умный молоток.
Заменят ли агенты разработчиков? Нет.
Заменят ли тех, кто умеет только писать код по принесённому ТЗ? Вот тут я бы призадумался. Впрочем, спрос на таких сокращался и до распространения агентов.
Знаете, кого точно заменят? Того, кто снимает с себя ответственность словами типа "это не я, это клод написал". Впрочем, это уже часть следующего поста..
Disclaimer: постов будет 2, второй — «Почему заменят» 🙃
———
Давайте отмотаем.
Когда-то код писали на перфокартах. Были специально обученные люди, которые переносили программу с бумажки на картонку с дырками.
До сих пор помню, как препод по информатике рассказывала и показывала, как машины всасывали перфокарты... поднося 4 пальца правой руки ко рту и имитировала всасывающие звуки. Так, что-то я не туда ушел. Ольга Михайловна, мое почтение, надеюсь всё хорошо у вас.
Так вот. Появились терминалы с текстовыми редакторами, и первая обслуживающая программистов профессия исчезла. Программисты остались.
Потом появился Notepad++ с подсветкой синтаксиса.
Потом появились IDE. Половина продолжала писать в блокноте, потому что тормозит.
Потом появился автокомплит.
Потом IntelliSense, который дописывает строку целиком.
Потом Copilot.
Агенты — следующая ступенька.
Смотрю на это как на очень продвинутый автокомплит, который дописывает согласованный код сразу во много связанных друг с другом файлов.
Но это тула. И у тулы пока нет важнейших свойств, из-за чего она никого не заменит.
1️⃣ — У тулы нет страха смерти
Кожаный держится за рабочее место, потому что иначе будет уволен и умрёт под мостом от голода. Именно поэтому он придёт на работу утром в понедельник, доделает неприятную задачу, возьмёт трубку в три ночи и починит прод.
У агента нет ипотеки и детей. Он выключился и не вспомнит, что было.
2️⃣ — У тулы нет ответственности
— Да, я дропнул продакшен базу. Надо было сначала сделать бэкап.
(и нихрена ты мне за это не сделаешь, кожаный ублюдок)
Кого будят ночью? Кто пишет постмортем? Кого зовут к СТО объясняться?
Кожаного оператора ллм. Того, кто кнопки жмёт.
Пока ответственность на человеке, человек будет в цепочке.
———
Тула без человека не имеет применения. Молоток сам гвоздь не забьёт, даже очень умный молоток.
Заменят ли агенты разработчиков? Нет.
Заменят ли тех, кто умеет только писать код по принесённому ТЗ? Вот тут я бы призадумался. Впрочем, спрос на таких сокращался и до распространения агентов.
Знаете, кого точно заменят? Того, кто снимает с себя ответственность словами типа "это не я, это клод написал". Впрочем, это уже часть следующего поста..
👍31❤12🤣7🔥3👎2
Автономность команды. Больше = лучше?
Обычно автономность преподносится как безусловное добро:
«Чем больше автономии, тем более зрелая команда».
«Чем меньше вмешательства сверху, тем здоровее процессы».
Я и сам так говорил: полтора года назад расписал 5 уровней автономности сотрудника, где вершина — «сделал, работает, захочешь посмотреть — приходи». Пятый уровень считал целью для любой команды. Автономность команды по факту и есть уровень автономности её менеджера.
На этой неделе на ProductSense услышал у Евгения Васильева (директор по продукту ВКонтакте, VK Видео и VK Музыки) мысль, которая эту картину меняет. Пересказываю своими словами и со своими выводами.
Целевой уровень автономии зависит от того, что происходит вокруг команды.
В стабильной среде цели на год известны, соседи не меняются, стратегию никто не переписывает.
Автономия ускоряет: команда сама решает, сама катит, никого не ждёт. Контекст она подтягивает сама, когда он ей нужен. Любая эскалация и согласования тут — потеря времени.
При большой перестройке контекст меняется быстрее, чем его успевают разослать. Команда всё так же тянет его снизу, только тянет уже устаревший. И та же автономия начинает вредить.
Пример: Команда автономно пилит фичу и катит в прод. Когда информация о релизе доходит до CPO, выясняется, что контекст шире: соседний юнит уже делает похожее, стратегию поменяли, квартальные планы перестроили, бюджет на смски весь потратили на другую фичу.
Приходится вырубать фича-тогл. Месяц делали не то.
Отсюда два вывода, которые мне не нравятся, но приходится признавать.
1️⃣ — В период глобальных пертурбаций C-level в регулярной работе команды — норма
Год назад я бы назвал это микроменеджментом. Сейчас вижу иначе. Директор на еженедельном синке команды стоит дешевле, чем месяц работы команды в мусорку.
Ессно, у CPO тридцать команд и на все синки он не придёт. Ходит только к тем, кого перестройка задевает, и только пока она идёт.
2️⃣ — Зрелость менеджера видна по работе с масштабом задачи
Увидел, что задача больше его уровня -> собрал варианты с последствиями -> вовремя согласовал на достаточном уровне.
Потом отвечает за реализацию того, что выбрали.
Количество решений, принятых в одиночку, тут ни при чём.
Менеджер, который во время большого реорга гордо решает всё сам, просто позже узнает, что нарешал не то.
———
Что это меняет в моих 5 уровнях.
Уровень 3, «консультироваться, потом действовать», я считал промежуточной ступенькой.
Похоже, во время шторма он самый взрослый из пяти.
А пятый в этот момент опасен: команда быстро и уверенно едет по старой карте.
Автономию команды приходится крутить под контекст, как ручку громкости.
На полную в стабильности, тише в рывке.
Крутит руководитель, и ему же проговаривать команде, что это временно, иначе прочитают как недоверие.
Обычно автономность преподносится как безусловное добро:
«Чем больше автономии, тем более зрелая команда».
«Чем меньше вмешательства сверху, тем здоровее процессы».
Я и сам так говорил: полтора года назад расписал 5 уровней автономности сотрудника, где вершина — «сделал, работает, захочешь посмотреть — приходи». Пятый уровень считал целью для любой команды. Автономность команды по факту и есть уровень автономности её менеджера.
На этой неделе на ProductSense услышал у Евгения Васильева (директор по продукту ВКонтакте, VK Видео и VK Музыки) мысль, которая эту картину меняет. Пересказываю своими словами и со своими выводами.
Целевой уровень автономии зависит от того, что происходит вокруг команды.
В стабильной среде цели на год известны, соседи не меняются, стратегию никто не переписывает.
Автономия ускоряет: команда сама решает, сама катит, никого не ждёт. Контекст она подтягивает сама, когда он ей нужен. Любая эскалация и согласования тут — потеря времени.
При большой перестройке контекст меняется быстрее, чем его успевают разослать. Команда всё так же тянет его снизу, только тянет уже устаревший. И та же автономия начинает вредить.
Пример: Команда автономно пилит фичу и катит в прод. Когда информация о релизе доходит до CPO, выясняется, что контекст шире: соседний юнит уже делает похожее, стратегию поменяли, квартальные планы перестроили, бюджет на смски весь потратили на другую фичу.
Приходится вырубать фича-тогл. Месяц делали не то.
Отсюда два вывода, которые мне не нравятся, но приходится признавать.
1️⃣ — В период глобальных пертурбаций C-level в регулярной работе команды — норма
Год назад я бы назвал это микроменеджментом. Сейчас вижу иначе. Директор на еженедельном синке команды стоит дешевле, чем месяц работы команды в мусорку.
Ессно, у CPO тридцать команд и на все синки он не придёт. Ходит только к тем, кого перестройка задевает, и только пока она идёт.
2️⃣ — Зрелость менеджера видна по работе с масштабом задачи
Увидел, что задача больше его уровня -> собрал варианты с последствиями -> вовремя согласовал на достаточном уровне.
Потом отвечает за реализацию того, что выбрали.
Количество решений, принятых в одиночку, тут ни при чём.
Менеджер, который во время большого реорга гордо решает всё сам, просто позже узнает, что нарешал не то.
———
Что это меняет в моих 5 уровнях.
Уровень 3, «консультироваться, потом действовать», я считал промежуточной ступенькой.
Похоже, во время шторма он самый взрослый из пяти.
А пятый в этот момент опасен: команда быстро и уверенно едет по старой карте.
Автономию команды приходится крутить под контекст, как ручку громкости.
На полную в стабильности, тише в рывке.
Крутит руководитель, и ему же проговаривать команде, что это временно, иначе прочитают как недоверие.
Telegram
Product Developer
5 Уровней автономности сотрудника
В прошлых постах я рассказывал, почему менеджеру не стоит забирать задачи сотрудников. Теперь рассмотрим этот вопрос с другой стороны:
Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?…
В прошлых постах я рассказывал, почему менеджеру не стоит забирать задачи сотрудников. Теперь рассмотрим этот вопрос с другой стороны:
Как сотруднику понять, с какими задачами идти к тимлиду, а какие решать самостоятельно?…
👍24🔥9❤5👎2
Кого и почему заменят AI-агенты
Пост наполнен ненавистью, я вас предупредил.
Это вторая часть, первая тут.
В прошлый раз я писал, что AI-агент — это тула, и тула сама по себе никого не заменит.
Это как если бы сисадмины боялись, что ci/cd пайплайны их заменят.
На текущем этапе я бы не стал готовиться к тому, что у нас будут AI-сокомандники, и им нужно будет писать "доброе утро" в командных чатах.
Но! Тула делает ценнее того, кто умеет ей пользоваться, поэтому заменят на самом деле не AI-агенты, а люди, которые умеют ими пользоваться.
Без современного тулинга сейчас уже просто невозможно успеть сделать достаточный объем работы, чтобы не выглядеть лоу-перформером на фоне сокомандников. Серьёзно. Если вы ждали какого-то сигнала, вот он. Поставьте себе Клода или Кодекс, заплатите 20 баксов и начинайте учиться.
Но предупреждаю о последствиях и зависимости.
Возникнет неконтролируемое и неосознанное желание отдаться AI-агенту полностью:
— принимать решения чисто как клод говорит
— общаться с коллегами прямо копипастя туда-сюда текстовки
— писать документы и не вычитывать их
Это экономит когнитивный ресурс, а человек — существо ленивое.
Поэтому очень легко стать "мясным прокси" без добавленной ценности.
И вот таких заменят в первую очередь.
Во-первых, потому что они начинают приносить больше вреда, чем пользы.
Во-вторых, просто потому что они очень бесят.
За прошедший месяц у меня было три бесячих ситуации от трёх разных людей.
———
Ситуация 1. Продакт составил документ по новой инициативе для внутренней защиты. С техническими деталями и архитектурой, но очень странными. Как позже выяснилось, тимлида и инженеров продакт не привлекал.
— Паша (обращаюсь к тимлиду), есть пара уточнений по архитектуре, можем сейчас обсудить?
— Впервые вижу эту архитектуру, док без меня готовил Вадим.
— Вадим (обращаюсь к продакту), подскажи пожалуйста: ... (пара сутевых вопросов)
— Не знаю, это клод нарисовал, я тут вообще не шарю, думал Паша расскажет.
— ¿?¡!
———
Ситуация 2. Скидывают документ на 11 страниц, "почитать". То что слог слоповатый и постоянно противопоставления "это не тёплое, это мягкое" — подбешивает, но ладно, уже привык.
К сутевой части возникли вопросы. Внутри в том числе организационный сетап новой команды и перечислено, кого надо нанять.
Читаю: собрались нанимать сисадмина в команду. Это очень странно, потому что инициатива продуктовая и должна по идее спокойно лечь поверх текущей техплатформы. А если и нанимать сисадмина, то опять же в техплатформу. В продуктовой команде ему просто нечего будет делать.
Задаю вопрос. Оказывается, эту часть читать не надо было. Документ читать надо вместе с автором на встрече, чтобы он показывал пальцем: «тут читай, тут не читай, тут ллм нафантазировал».
Бл#%ть! Почему я должен тратить время на чтение документов, на написание которых автор не потратил времени?! Это тупо неуважение к читателю.
———
Ситуация 3. Общаемся в чате с руководителем соседнего юнита на тему передачи одного инженера в его команду. С моей стороны запрос: покажите роадмап, чем будет этот инженер заниматься, и где там конечная точка чтобы поддержать нашу инициативу. А чувак кажется просто в чатжпт скармливает мои вопросы и копипастит ответ.
Читать невозможно: плотность смысла около нуля, странные термины, через абзац опять же «это не тёплое, это мягкое».
И в этой переписке решается, передавать ли одного живого FTE из команды в команду.
Судьбу человека решает чатжпт. Менеджер при нём — просто мясной прокси.
Бесит.
———
Что общего у всех троих — отсутствие добавленной ценности к тому, что выдал агент. Ни проверки, ни принятия решения, ни ответственности. Уберите их из цепочки, результат не изменится.
Заменят ли агенты кожаных? Вот таких — да.
Хорошая напоминалочка каждому: почаще задаваться вопросом "а какая моя добавочная ценность?"
Иногда и сам себя ловлю на том, что не полностью вычищенные документы коллегам отправляю..
Пост наполнен ненавистью, я вас предупредил.
Это вторая часть, первая тут.
В прошлый раз я писал, что AI-агент — это тула, и тула сама по себе никого не заменит.
Это как если бы сисадмины боялись, что ci/cd пайплайны их заменят.
На текущем этапе я бы не стал готовиться к тому, что у нас будут AI-сокомандники, и им нужно будет писать "доброе утро" в командных чатах.
Но! Тула делает ценнее того, кто умеет ей пользоваться, поэтому заменят на самом деле не AI-агенты, а люди, которые умеют ими пользоваться.
Без современного тулинга сейчас уже просто невозможно успеть сделать достаточный объем работы, чтобы не выглядеть лоу-перформером на фоне сокомандников. Серьёзно. Если вы ждали какого-то сигнала, вот он. Поставьте себе Клода или Кодекс, заплатите 20 баксов и начинайте учиться.
Но предупреждаю о последствиях и зависимости.
Возникнет неконтролируемое и неосознанное желание отдаться AI-агенту полностью:
— принимать решения чисто как клод говорит
— общаться с коллегами прямо копипастя туда-сюда текстовки
— писать документы и не вычитывать их
Это экономит когнитивный ресурс, а человек — существо ленивое.
Поэтому очень легко стать "мясным прокси" без добавленной ценности.
И вот таких заменят в первую очередь.
Во-первых, потому что они начинают приносить больше вреда, чем пользы.
Во-вторых, просто потому что они очень бесят.
За прошедший месяц у меня было три бесячих ситуации от трёх разных людей.
———
Ситуация 1. Продакт составил документ по новой инициативе для внутренней защиты. С техническими деталями и архитектурой, но очень странными. Как позже выяснилось, тимлида и инженеров продакт не привлекал.
— Паша (обращаюсь к тимлиду), есть пара уточнений по архитектуре, можем сейчас обсудить?
— Впервые вижу эту архитектуру, док без меня готовил Вадим.
— Вадим (обращаюсь к продакту), подскажи пожалуйста: ... (пара сутевых вопросов)
— Не знаю, это клод нарисовал, я тут вообще не шарю, думал Паша расскажет.
— ¿?¡!
———
Ситуация 2. Скидывают документ на 11 страниц, "почитать". То что слог слоповатый и постоянно противопоставления "это не тёплое, это мягкое" — подбешивает, но ладно, уже привык.
К сутевой части возникли вопросы. Внутри в том числе организационный сетап новой команды и перечислено, кого надо нанять.
Читаю: собрались нанимать сисадмина в команду. Это очень странно, потому что инициатива продуктовая и должна по идее спокойно лечь поверх текущей техплатформы. А если и нанимать сисадмина, то опять же в техплатформу. В продуктовой команде ему просто нечего будет делать.
Задаю вопрос. Оказывается, эту часть читать не надо было. Документ читать надо вместе с автором на встрече, чтобы он показывал пальцем: «тут читай, тут не читай, тут ллм нафантазировал».
Бл#%ть! Почему я должен тратить время на чтение документов, на написание которых автор не потратил времени?! Это тупо неуважение к читателю.
———
Ситуация 3. Общаемся в чате с руководителем соседнего юнита на тему передачи одного инженера в его команду. С моей стороны запрос: покажите роадмап, чем будет этот инженер заниматься, и где там конечная точка чтобы поддержать нашу инициативу. А чувак кажется просто в чатжпт скармливает мои вопросы и копипастит ответ.
Читать невозможно: плотность смысла около нуля, странные термины, через абзац опять же «это не тёплое, это мягкое».
И в этой переписке решается, передавать ли одного живого FTE из команды в команду.
Судьбу человека решает чатжпт. Менеджер при нём — просто мясной прокси.
Бесит.
———
Что общего у всех троих — отсутствие добавленной ценности к тому, что выдал агент. Ни проверки, ни принятия решения, ни ответственности. Уберите их из цепочки, результат не изменится.
Заменят ли агенты кожаных? Вот таких — да.
Хорошая напоминалочка каждому: почаще задаваться вопросом "а какая моя добавочная ценность?"
Иногда и сам себя ловлю на том, что не полностью вычищенные документы коллегам отправляю..
💯50❤16🔥15👍3🌚2