Рекрутеров можно заменить броском монеты
Ребята, которые делают сервис мок-собеседований interviewing.io провели офигенный эксперимент. Они попросили 76 технических рекрутеров отсмотреть по 30 резюме, и ответить на два вопроса:
1️⃣Позвали ли бы вы этого кандидата на собеседование?
2️⃣Какая вероятность того, что этот кандидат пройдет техническое собеседование?
Ответы рекрутеров сравнивали с реальными данными о том, с каким успехом эти кандидаты проходили мок-интервью. При этом отдельные рисерчи уже показали высокую корреляцию между прохождением таких типов интервью и последующим наймом. Короче, выводы такие:
👉Рекрутеры правильно решают пригласить кандидата на интервью только в 55% случаев. По сути, аналогично броску монеты.
👉Кандидаты, которым рекрутеры дали 0-5% вероятность прохождения интервью, на самом деле успешно прошли его в 47% случаев.
👉Кандидаты, в успешности интервью которых рекрутеры были уверены на 95-100%, прошли интервью только в 64% случаев.
👉В среднем разница в оценке вероятности прохождения интервью для одного и того же кандидата между двумя рекрутерами – 41%.
👉Декларируемые рекрутерами причины отказа от резюме не соответствуют реальным предикторам отказа.
👉Обученные на коленке ML-модели показали заметно более точные результаты в оценке резюме.
Расскажите в комментариях, почему, даже при таком раскладе, вы все еще подключаете рекрутеров в качестве фильтра входящего потока резюме.
Ребята, которые делают сервис мок-собеседований interviewing.io провели офигенный эксперимент. Они попросили 76 технических рекрутеров отсмотреть по 30 резюме, и ответить на два вопроса:
1️⃣Позвали ли бы вы этого кандидата на собеседование?
2️⃣Какая вероятность того, что этот кандидат пройдет техническое собеседование?
Ответы рекрутеров сравнивали с реальными данными о том, с каким успехом эти кандидаты проходили мок-интервью. При этом отдельные рисерчи уже показали высокую корреляцию между прохождением таких типов интервью и последующим наймом. Короче, выводы такие:
👉Рекрутеры правильно решают пригласить кандидата на интервью только в 55% случаев. По сути, аналогично броску монеты.
👉Кандидаты, которым рекрутеры дали 0-5% вероятность прохождения интервью, на самом деле успешно прошли его в 47% случаев.
👉Кандидаты, в успешности интервью которых рекрутеры были уверены на 95-100%, прошли интервью только в 64% случаев.
👉В среднем разница в оценке вероятности прохождения интервью для одного и того же кандидата между двумя рекрутерами – 41%.
👉Декларируемые рекрутерами причины отказа от резюме не соответствуют реальным предикторам отказа.
👉Обученные на коленке ML-модели показали заметно более точные результаты в оценке резюме.
Расскажите в комментариях, почему, даже при таком раскладе, вы все еще подключаете рекрутеров в качестве фильтра входящего потока резюме.
Как работать с друзьями
Кажется, я еще не рассказывал в канале историю своего первого увольнения. Я работал в небольшой студии разработки обычным мобильщиком. В какой-то момент наш руководитель начал искать дизайнера в команду, и я порекомендовал ему своего давнего приятеля, с которым у нас за плечами было уже несколько запущенных пет-проектов. Проблемы с ним начались практически сразу же. Например, он часто не появляться в офисе половину дня, а вторую – спал в гамаке. Потом в какой-то момент он решил откосить от армии, и несколько дней у всех в офисе пытался занять деньги на покупку военника. Ну и, главная проблема – продалбывал абсолютно все сроки и договоренности.
Спустя несколько месяцев такой работы меня похлопали по плечу и сказали: "Ты его привел, ты и увольняй". И это был максимально тяжелый опыт, ведь мне надо было не просто уволить первого в своем опыте человека, но еще и моего дружаню. Короче, репетировал разговория неделю, делал это практически сквозь слезы, и получилось довольно невнятно.
Наверное, эта ситуация должна была научить меня не работать с друзьями, чтобы не сталкиваться с таким стрессом в будущем – но я в целом учусь плохо, поэтому нанимать друзей я продолжил, хоть увольнять мне больше их и не приходилось. И в целом дальше опыт совместной работы с ними был очень вознаграждающим, 10/10.
Так вот, к чему эта подводка. На днях вышел новый выпуск подкаста "Три тимлида заходят в бар", который бьет прямо в эту тему – как работать с друзьями, нанимать их, расставлять границы, и, если все пошло плохо, увольнять. Хороший подкаст, послушайте!
Кажется, я еще не рассказывал в канале историю своего первого увольнения. Я работал в небольшой студии разработки обычным мобильщиком. В какой-то момент наш руководитель начал искать дизайнера в команду, и я порекомендовал ему своего давнего приятеля, с которым у нас за плечами было уже несколько запущенных пет-проектов. Проблемы с ним начались практически сразу же. Например, он часто не появляться в офисе половину дня, а вторую – спал в гамаке. Потом в какой-то момент он решил откосить от армии, и несколько дней у всех в офисе пытался занять деньги на покупку военника. Ну и, главная проблема – продалбывал абсолютно все сроки и договоренности.
Спустя несколько месяцев такой работы меня похлопали по плечу и сказали: "Ты его привел, ты и увольняй". И это был максимально тяжелый опыт, ведь мне надо было не просто уволить первого в своем опыте человека, но еще и моего дружаню. Короче, репетировал разговория неделю, делал это практически сквозь слезы, и получилось довольно невнятно.
Наверное, эта ситуация должна была научить меня не работать с друзьями, чтобы не сталкиваться с таким стрессом в будущем – но я в целом учусь плохо, поэтому нанимать друзей я продолжил, хоть увольнять мне больше их и не приходилось. И в целом дальше опыт совместной работы с ними был очень вознаграждающим, 10/10.
Так вот, к чему эта подводка. На днях вышел новый выпуск подкаста "Три тимлида заходят в бар", который бьет прямо в эту тему – как работать с друзьями, нанимать их, расставлять границы, и, если все пошло плохо, увольнять. Хороший подкаст, послушайте!
4 выпуск 1 сезона
Работа с друзьями — умение расставлять границы или неизбежный непотизм? — Подкаст «Три тимлида заходят в бар»
Иногда мы, как руководители, встаем перед выбором: нанять на работу кого-то из друзей или нет. Иногда такого выбора даже и нет: вы работали с кем-то и подружились, а потом непредсказуемые потоки карьеры вынесли одного из вас к руководству другим. В ч
Подборка книг по продакт-менеджменту
Я часто говорю тут о том, что большинству тимлидов нужно регулярно подкачивать свои продуктовые навыки. Держите отличную подборку книг по теме. От себя из нее вдвойне плюсую следующие:
👉Chrossing the Chasm, объясняющая, как выглядит цикл адопшна новых продуктов и технологий.
👉Escaping the Build Trap, про то, как работают фиче-фабрики, и как это прекратить.
👉Sprint, хороший фреймворк, с помощью которого всего за неделю вы можете получить работающий прототип своей идеи.
Я часто говорю тут о том, что большинству тимлидов нужно регулярно подкачивать свои продуктовые навыки. Держите отличную подборку книг по теме. От себя из нее вдвойне плюсую следующие:
👉Chrossing the Chasm, объясняющая, как выглядит цикл адопшна новых продуктов и технологий.
👉Escaping the Build Trap, про то, как работают фиче-фабрики, и как это прекратить.
👉Sprint, хороший фреймворк, с помощью которого всего за неделю вы можете получить работающий прототип своей идеи.
Ken Norton Coaching
Best Books for Product Managers [2024]
Ken Norton shares his recommended books for product managers. The best books on product leadership, innovation, management, shipping winning products, and design thinking.
Как управлять bottleneck командой
Частый организационный антипаттерн в большой компании – команда, стоящая на критическом пути сразу большого количества проектов. Например, такая команда может отвечать за какой-то общий API, доработки в котором регулярно требуются многим общим клиентам. Или отвечать за все базы данных.
На увеличение time to market влияет не только сам факт обособленности команды, но еще и то, что с ростом компании такие команды не всегда растут теми же самыми темпами. А это влечет за собой рост количества клиентов, размазывание ресурсов команды еще более тонким слоем, растущий бэклог невыполненных задач и еще более растущий TTM.
Несколько советов из статьи для менеджеров таких команд:
👉Проблемы такого рода часто растут из архитектуры. Попробуйте привлечь нескольких независимых людей, чтобы они со стороны оценили вашу ситуацию и подсветили бы какие-то слепые пятна.
👉Найдите способ держать ваш менеджмент в курсе ситуации в команде, того, по каким причинам вы не справляетесь со всеми запросами, и как выстраиваете приоритизацию. Вам нужно получить защиту от так называемого stakeholder bullying, когда разные менеджеры с громкими тайтлами будут пытаться продавливать вас, чтобы их фича вышла в топ бэклога.
👉Подумайте, есть ли возможность перейти из сервисной в платформенную команду – и вместо выполнения работы за других людей давать им удобную платформу, которой они смогут пользоваться целиком без вас.
👉Рассмотрите подход внутреннего open source, когда люди из других команд могут сами делать нужные им фичи, а вы только принимаете PR.
👉Установите режим дежурств, в котором все входящие запросы к команде в каждый момент времени направляются строго на одного человека.
Частый организационный антипаттерн в большой компании – команда, стоящая на критическом пути сразу большого количества проектов. Например, такая команда может отвечать за какой-то общий API, доработки в котором регулярно требуются многим общим клиентам. Или отвечать за все базы данных.
На увеличение time to market влияет не только сам факт обособленности команды, но еще и то, что с ростом компании такие команды не всегда растут теми же самыми темпами. А это влечет за собой рост количества клиентов, размазывание ресурсов команды еще более тонким слоем, растущий бэклог невыполненных задач и еще более растущий TTM.
Несколько советов из статьи для менеджеров таких команд:
👉Проблемы такого рода часто растут из архитектуры. Попробуйте привлечь нескольких независимых людей, чтобы они со стороны оценили вашу ситуацию и подсветили бы какие-то слепые пятна.
👉Найдите способ держать ваш менеджмент в курсе ситуации в команде, того, по каким причинам вы не справляетесь со всеми запросами, и как выстраиваете приоритизацию. Вам нужно получить защиту от так называемого stakeholder bullying, когда разные менеджеры с громкими тайтлами будут пытаться продавливать вас, чтобы их фича вышла в топ бэклога.
👉Подумайте, есть ли возможность перейти из сервисной в платформенную команду – и вместо выполнения работы за других людей давать им удобную платформу, которой они смогут пользоваться целиком без вас.
👉Рассмотрите подход внутреннего open source, когда люди из других команд могут сами делать нужные им фичи, а вы только принимаете PR.
👉Установите режим дежурств, в котором все входящие запросы к команде в каждый момент времени направляются строго на одного человека.
Rubick
Jade Rubick - Managing a bottleneck team
Feel like your team is the bottleneck? Learn how to address the challenges of managing a bottleneck team.
Исследование рынка продактов 2024
Подъехали результаты большого исследования рынка русскоязычных продакт-менеджеров. Про предыдущее я писал аж полтора года назад, и за это время изменилось очень многое!
👉Работать продактам стало спокойнее. Интенсивность изменений процессов в компаниях стала меньше, а управлять собственным временем респонденты стали в два раза лучше. Но при этом работа в условиях большой нагрузки продолжает оставаться главной сложностью в работе.
👉Больше всего времени уходит на встречи и общение, налаживание процессов и планирование. Причем встречи съедают у большинства около 40% всего рабочего ресурса.
👉Половина продактов тратят на общение с пользователями в любом виде 10% времени или даже меньше. Это как-то очень мало и грустно.
👉Продакты – те еще выгорашки. Только 6% отвеченных сказали, что никогда не выгорали. Ну это и понятно – больше половины опрошенных работают не только в будни, но еще и в выходные.
👉Главные языки программирования среди продактов – SQL и Python.
👉Продакты продолжают постоянно вкладываться в свое обучение. 40% опрошенных тратят на это больше трех часов в неделю.
👉Вне России работают 24% опрошенных. Из оставшихся две трети не планируют релоцироваться.
👉Продакты всегда остаются открыты миру. В активном поиске работы находится только каждый десятый, но при этом половина готовы рассмотреть предложение о новой работе. Среди интересных сфер деятельности лидируют банки, екоммерс и образование. Наличие там банков мне, конечно, никогда не понять.
В этот раз еще отдельно разобрали вопрос зарплат:
💰Джуны в основном получают до 150к
💰У мидлов разброс от 100 до 350к
💰У сеньоров разброс 250-450к
💰У хедов и CPO – 250-600к, причем у 40% CPO зарплата выходит за пределы 600к.
Подъехали результаты большого исследования рынка русскоязычных продакт-менеджеров. Про предыдущее я писал аж полтора года назад, и за это время изменилось очень многое!
👉Работать продактам стало спокойнее. Интенсивность изменений процессов в компаниях стала меньше, а управлять собственным временем респонденты стали в два раза лучше. Но при этом работа в условиях большой нагрузки продолжает оставаться главной сложностью в работе.
👉Больше всего времени уходит на встречи и общение, налаживание процессов и планирование. Причем встречи съедают у большинства около 40% всего рабочего ресурса.
👉Половина продактов тратят на общение с пользователями в любом виде 10% времени или даже меньше. Это как-то очень мало и грустно.
👉Продакты – те еще выгорашки. Только 6% отвеченных сказали, что никогда не выгорали. Ну это и понятно – больше половины опрошенных работают не только в будни, но еще и в выходные.
👉Главные языки программирования среди продактов – SQL и Python.
👉Продакты продолжают постоянно вкладываться в свое обучение. 40% опрошенных тратят на это больше трех часов в неделю.
👉Вне России работают 24% опрошенных. Из оставшихся две трети не планируют релоцироваться.
👉Продакты всегда остаются открыты миру. В активном поиске работы находится только каждый десятый, но при этом половина готовы рассмотреть предложение о новой работе. Среди интересных сфер деятельности лидируют банки, екоммерс и образование. Наличие там банков мне, конечно, никогда не понять.
В этот раз еще отдельно разобрали вопрос зарплат:
💰Джуны в основном получают до 150к
💰У мидлов разброс от 100 до 350к
💰У сеньоров разброс 250-450к
💰У хедов и CPO – 250-600к, причем у 40% CPO зарплата выходит за пределы 600к.
Про фидбэк луп
Одна из главных причин фрустрации при переходе из индивидуального контрибьютора в лиды в резком увеличении длины цикла обратной связи о том, что ты молодец, и предпринятые тобой действия влияют на итоговый результат. Когда ты разработчик все сравнительно просто. Фидбэк лупов много, и все они довольно короткие:
🔄Написал код – скомпилировал – увидел результат
🔄Доделал таску – отправил PR на ревью – получил комментарии
🔄Смерджил ветку в мастер – дождался релиза – потрогал новую фичу руками и показал своей маме
А вот с тимлидами все намного сложнее. Вроде бы ты помог команде начать работать чуть эффективнее, убрав что-то, что ей мешало, но как сказались именно твои действия на итоговом результате – черт его знает. Из-за этого многие тимлиды и пытаются заменить сложное простым, вводя различные дурацкие метрики, и пытаясь на них повлиять.
Я знаю только один нормальный способ с этим жить, и в заметке по ссылке предлагают его же. Во-первых, смиритесь с тем, что цикл обратной связи о результатах руководителя – долгий и довольно неявный. Это, к сожалению, не изменить. Во-вторых, старайтесь сами декомпозировать свою работу на маленькие кусочки и вести дневник своих маленьких побед. Например, иногда достаточно просто быстро опросить команду на тему того, насколько им стало лучше жить после какого-то изменения в процессах, чтобы понять, что свою работу вы сделали не зря.
Одна из главных причин фрустрации при переходе из индивидуального контрибьютора в лиды в резком увеличении длины цикла обратной связи о том, что ты молодец, и предпринятые тобой действия влияют на итоговый результат. Когда ты разработчик все сравнительно просто. Фидбэк лупов много, и все они довольно короткие:
🔄Написал код – скомпилировал – увидел результат
🔄Доделал таску – отправил PR на ревью – получил комментарии
🔄Смерджил ветку в мастер – дождался релиза – потрогал новую фичу руками и показал своей маме
А вот с тимлидами все намного сложнее. Вроде бы ты помог команде начать работать чуть эффективнее, убрав что-то, что ей мешало, но как сказались именно твои действия на итоговом результате – черт его знает. Из-за этого многие тимлиды и пытаются заменить сложное простым, вводя различные дурацкие метрики, и пытаясь на них повлиять.
Я знаю только один нормальный способ с этим жить, и в заметке по ссылке предлагают его же. Во-первых, смиритесь с тем, что цикл обратной связи о результатах руководителя – долгий и довольно неявный. Это, к сожалению, не изменить. Во-вторых, старайтесь сами декомпозировать свою работу на маленькие кусочки и вести дневник своих маленьких побед. Например, иногда достаточно просто быстро опросить команду на тему того, насколько им стало лучше жить после какого-то изменения в процессах, чтобы понять, что свою работу вы сделали не зря.
Kartikay's Blog
Feedback Loops
Everything is dependent on feedback loops. Video games/reels have short exciting feedback loops. That is why they are so addictive. Real life often has long ...
Как проджекту и продакту получить бриллиантовый оффер
Почти 80% проджектов и продактов не могут найти себе нормальную работу с отличной зарплатой и адекватным начальником. А всё потому что не умеют правильно оценивать свой опыт, проходить собеседования и чётко формулировать зарплатные ожидания.
Из этого рождаются абьюзивные отношения с говнокомпаниями, которые не хуже Марата Башарова бьют под дых и роняют всё профессиональное либидо.
Бывает ли по-другому?
Карьерный Цех доказывает, что ДА.
Ребята уже давно закрывают вакансии в ТОПовых компаниях России и точно знают, каким должен быть сотрудник, чтобы ему выкатили идеальный оффер.
Карьерный Цех берёт проджекта за руку, учит правильно искать работу и приводит к вакансии мечты.
Эксперты сопровождения научат правильно проходить собеседования, укажут на пробелы в hard- и soft-skills и приведут за руку в тусовку, где каждый найдёт крутой нетворк.
Знания о поиске работы, которые даёт Карьерный Цех, будут работать и через 5, и через 10, и даже 20 лет.
Как познакомиться с проектом поближе:
Переходите на сайт и записывайтесь на бесплатную консультацию. После консультации вы получите индивидуальный план поиска работы, который поможет получить бриллиантовый оффер.
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Почти 80% проджектов и продактов не могут найти себе нормальную работу с отличной зарплатой и адекватным начальником. А всё потому что не умеют правильно оценивать свой опыт, проходить собеседования и чётко формулировать зарплатные ожидания.
Из этого рождаются абьюзивные отношения с говнокомпаниями, которые не хуже Марата Башарова бьют под дых и роняют всё профессиональное либидо.
Бывает ли по-другому?
Карьерный Цех доказывает, что ДА.
Ребята уже давно закрывают вакансии в ТОПовых компаниях России и точно знают, каким должен быть сотрудник, чтобы ему выкатили идеальный оффер.
Карьерный Цех берёт проджекта за руку, учит правильно искать работу и приводит к вакансии мечты.
Эксперты сопровождения научат правильно проходить собеседования, укажут на пробелы в hard- и soft-skills и приведут за руку в тусовку, где каждый найдёт крутой нетворк.
Знания о поиске работы, которые даёт Карьерный Цех, будут работать и через 5, и через 10, и даже 20 лет.
Как познакомиться с проектом поближе:
Переходите на сайт и записывайтесь на бесплатную консультацию. После консультации вы получите индивидуальный план поиска работы, который поможет получить бриллиантовый оффер.
Реклама. ИП Федоров Е.П.
ИНН 532008901966
Культурный контракт с сотрудником
Я большой фанат прописывания явных ожидания между менеджером и сотрудником. Лично у меня с каждым человеком заведен общий документ в Notion, в котором описаны базовые ожидания от его роли, кастомные ожидания, зависящие от конкретной области ответственности, и личные цели на какой-то промежуток времени. Формат может немного различаться для разных людей в зависимости от их уровня зрелости и автономности, но я всегда стараюсь фиксировать их письменно.
Мои ожидания крутятся вокруг того, что именно человек должен делать, и как его работа будет оцениваться. Но сегодняшняя статья явно подсветила недостаток моей системы ожиданий – она ничего не говорит про то, КАК именно человек должен подходить к работе. Короче говоря, ничего не говорит про культурный код и принципы. Для старичков это не особо осмысленное вложение времени, а вот для людей, которые только пришли в компанию, выравниваться на уровне принципов поведения – супер-важно для их успеха.
Вот некоторые из пунктов, которые в такой культурный контракт включает автор статьи:
👉Не бойтесь говорить правду руководителю
👉Сначала научитесь играть по правилам, потом придумывайте свои
👉Сначала решать сложную ситуацию, а потом разбираться, кто в виноват в ее возникновении
👉Прояснять ожидания и соблюдать договоренности
👉Каждый сам отвечает за свой выбор
Звучат принципы, конечно, как за все хорошее против всего плохого. Чтобы такая система завелась, помимо бумажки с их списком каждый принцип нужно разбирать на реальных примерах, и, самое главное, регулярно самому их демонстрировать.
Я большой фанат прописывания явных ожидания между менеджером и сотрудником. Лично у меня с каждым человеком заведен общий документ в Notion, в котором описаны базовые ожидания от его роли, кастомные ожидания, зависящие от конкретной области ответственности, и личные цели на какой-то промежуток времени. Формат может немного различаться для разных людей в зависимости от их уровня зрелости и автономности, но я всегда стараюсь фиксировать их письменно.
Мои ожидания крутятся вокруг того, что именно человек должен делать, и как его работа будет оцениваться. Но сегодняшняя статья явно подсветила недостаток моей системы ожиданий – она ничего не говорит про то, КАК именно человек должен подходить к работе. Короче говоря, ничего не говорит про культурный код и принципы. Для старичков это не особо осмысленное вложение времени, а вот для людей, которые только пришли в компанию, выравниваться на уровне принципов поведения – супер-важно для их успеха.
Вот некоторые из пунктов, которые в такой культурный контракт включает автор статьи:
👉Не бойтесь говорить правду руководителю
👉Сначала научитесь играть по правилам, потом придумывайте свои
👉Сначала решать сложную ситуацию, а потом разбираться, кто в виноват в ее возникновении
👉Прояснять ожидания и соблюдать договоренности
👉Каждый сам отвечает за свой выбор
Звучат принципы, конечно, как за все хорошее против всего плохого. Чтобы такая система завелась, помимо бумажки с их списком каждый принцип нужно разбирать на реальных примерах, и, самое главное, регулярно самому их демонстрировать.
Хабр
«Культурный контракт» с сотрудником
Идея Один из наиболее эффективных инструментов руководителя, который я пробовал, это заключать "культурный контракт" с каждым сотрудником при его приеме на работу. Не так давно было много хайпа вокруг...
Бреслав и Ложечкин про собеседования и найм
Подкастная пятница уже становится традицией канала! Сегодня принес вам релиз нового выпуска подкаста "Бреслав и Ложечкин", в котором подробно разбирается и то, как можно нанимать людей в стартапы, и то, в чем состоят минусы и плюсы сложного процесса, который сейчас работает в Амазоне.
Закидывайте в список прослушивания на выходные, делитесь фидбэком тут в комментариях или прямо в канале подкаста. А еще мы с недавних пор стали монтировать и видео, так что на Сашу и Андрея теперь можно еще и смотреть!
Подкастная пятница уже становится традицией канала! Сегодня принес вам релиз нового выпуска подкаста "Бреслав и Ложечкин", в котором подробно разбирается и то, как можно нанимать людей в стартапы, и то, в чем состоят минусы и плюсы сложного процесса, который сейчас работает в Амазоне.
Закидывайте в список прослушивания на выходные, делитесь фидбэком тут в комментариях или прямо в канале подкаста. А еще мы с недавних пор стали монтировать и видео, так что на Сашу и Андрея теперь можно еще и смотреть!
14 выпуск 1 сезона
Как собеседовать и нанимать людей: опыт Амазон и других компаний — Подкаст «Бреслав и Ложечкин»
Поговорили о подходе к найму людей, от наивно-интуитивного до структурированного и формального. Чему мы можем научиться у Amazon? Leadership Principles, Bar Raisers - как это работает (и не работает).Упомянутые в подкасте артефакты:— The Everything S
Про документацию
Кент Бек в своей рассылке наваливает базы про документацию. Суть идеи в том, что сама по себе документация никому не нужна. Что нужно – наличие ответов на конкретные вопросы, знание того, как работает система, и как ее изменять чтобы она не поломалась. И решение о том, нужна ли документация в конкретном месте или нет, это всегда трейдофф.
Факторы, говорящие о том, что документация нужна:
👉Большая потенциальная аудитория читателей. Условно говоря, документация для публичного фреймворка имеет намного больше смысла, чем внутреннего класса, который за все время увидит только три человека.
👉Стабильность. Чем меньше меняется система, и чем более она стабильна, тем меньше костов на поддержание актуальной документации, тем больше в ней смысла.
👉Низкая цена затрат на документацию. Если для того, чтобы написать доки, вы откладываете какие-то важные продуктовые задачи, приносящие ценность бизнесу – скорее всего, вы делаете что-то не так.
Вместо траты время на документацию, можно рассматореть альтернативные способы добиться того же результата:
👉Упрощать систему. Простому коду и архитектуре не нужна документация.
👉Живые коммуникации: парное программирование, рассказы про устройство системы, разговоры за обедом.
👉Тесты. Тут все понятно – при изменении системы приходится менять и тесты, поэтому они легко сохраняют свою релевантность.
Кент Бек в своей рассылке наваливает базы про документацию. Суть идеи в том, что сама по себе документация никому не нужна. Что нужно – наличие ответов на конкретные вопросы, знание того, как работает система, и как ее изменять чтобы она не поломалась. И решение о том, нужна ли документация в конкретном месте или нет, это всегда трейдофф.
Факторы, говорящие о том, что документация нужна:
👉Большая потенциальная аудитория читателей. Условно говоря, документация для публичного фреймворка имеет намного больше смысла, чем внутреннего класса, который за все время увидит только три человека.
👉Стабильность. Чем меньше меняется система, и чем более она стабильна, тем меньше костов на поддержание актуальной документации, тем больше в ней смысла.
👉Низкая цена затрат на документацию. Если для того, чтобы написать доки, вы откладываете какие-то важные продуктовые задачи, приносящие ценность бизнесу – скорее всего, вы делаете что-то не так.
Вместо траты время на документацию, можно рассматореть альтернативные способы добиться того же результата:
👉Упрощать систему. Простому коду и архитектуре не нужна документация.
👉Живые коммуникации: парное программирование, рассказы про устройство системы, разговоры за обедом.
👉Тесты. Тут все понятно – при изменении системы приходится менять и тесты, поэтому они легко сохраняют свою релевантность.
Please open Telegram to view this post
VIEW IN TELEGRAM
Про проблемы рабочей эмиграции
Я стараюсь периодически разваливать популярный миф о том, что тимлиду с бэкграундом работы в российских компаниях невозможно найти работу инжиниринг менеджером где-то в Европе. Я сам получал несколько таких офферов, и многие друзья таким же образом релоцировались в Европу, причем даже в последние годы, несмотря на общий кризис в IT.
Так вот, я обычно покрываю вопрос релокации сугубо с карьерной стороны, выкладывая материалы про прохождения собеседований, анализ текущего рынка вакансий и зарплат, и другие похожие материалы. Но переезд – это не только получение оффера, но и просто гигантское количество сложностей и стресса, связанного с обустройством на новом месте, адаптацией к новой культуре, поиску своей собственной идентичности. И сегодня я хочу посоветовать канал Кирилла Куликова, серийного предпринимателя и эмигранта с огромным стажем. Его канал – супер-ценный источник историй о том, как выбрать страну для переезда и пережить релокацию. Вот некоторые из постов:
👉Разбор актуальной статистике Евростата про жизнь в Европе: безопасность, доходы, уровень счастья и отказы во въезде.
👉Что не так с Нидерландами: тут база, с которой я в целом согласен.
👉Про обладание несколькими ВНЖ: почему это легально, зачем это нужно, и откуда их взять.
Все остальные посты про эмиграцию можно найти не только в канале, но и в базе знаний в Notion. Даже задумался, чтобы себе такую же завести! А вообще, подписывайтесь на канал – помимо эмигрантских заметок там еще много хорошего про стартапы и предпринимательство.
Я стараюсь периодически разваливать популярный миф о том, что тимлиду с бэкграундом работы в российских компаниях невозможно найти работу инжиниринг менеджером где-то в Европе. Я сам получал несколько таких офферов, и многие друзья таким же образом релоцировались в Европу, причем даже в последние годы, несмотря на общий кризис в IT.
Так вот, я обычно покрываю вопрос релокации сугубо с карьерной стороны, выкладывая материалы про прохождения собеседований, анализ текущего рынка вакансий и зарплат, и другие похожие материалы. Но переезд – это не только получение оффера, но и просто гигантское количество сложностей и стресса, связанного с обустройством на новом месте, адаптацией к новой культуре, поиску своей собственной идентичности. И сегодня я хочу посоветовать канал Кирилла Куликова, серийного предпринимателя и эмигранта с огромным стажем. Его канал – супер-ценный источник историй о том, как выбрать страну для переезда и пережить релокацию. Вот некоторые из постов:
👉Разбор актуальной статистике Евростата про жизнь в Европе: безопасность, доходы, уровень счастья и отказы во въезде.
👉Что не так с Нидерландами: тут база, с которой я в целом согласен.
👉Про обладание несколькими ВНЖ: почему это легально, зачем это нужно, и откуда их взять.
Все остальные посты про эмиграцию можно найти не только в канале, но и в базе знаний в Notion. Даже задумался, чтобы себе такую же завести! А вообще, подписывайтесь на канал – помимо эмигрантских заметок там еще много хорошего про стартапы и предпринимательство.
Telegram
kyrillic
Заметки сооснователя стартапа Beau (YC S21)
Пишу то, что нельзя нагуглить про стартапы, эмиграцию, востребованность в мире, номадизм и др.
Архив содержательных постов http://bit.ly/kyrillic-archive (удобно!)
Контакт @kyrillicobot
Пишу то, что нельзя нагуглить про стартапы, эмиграцию, востребованность в мире, номадизм и др.
Архив содержательных постов http://bit.ly/kyrillic-archive (удобно!)
Контакт @kyrillicobot
Джунов нельзя заменять на AI
Шикарное эссе про то, почему даже с повышением качества и предсказуемости работы AI вам нужно нанимать джунов.
Основная ценность сеньорного инженера – уметь строить надежные, поддерживаемые и понятные системы из меньших блоков. Умение управлять сложной социотехнической системой приходит только с опытом работы в индустрии, методом проб и ошибок и обучения у старших товарищей. Написание простого кода действительно с рядом оговорок можно отдать AI, но вы теряете кучу других важных преимуществ от наличия джунов в команде, включая здоровую групповую динамику, культуру наставничества, да и вообще воронку появления новых сеньоров.
Основной боттлнек индустрии – не развитие джунов, а их найм. Компании не хотят инвестировать в неопытных инженеров, ценность наличия которых в команде сложнее переводится в деньги, чем сеньоров. Именно отсюда и берется постепенное повышение планки найма и невозможность начинающему специалисту найти работу. Повлиять на это могут только сами нанимающие менеджеры, убеждая свое руководство в необходимости найма джунов. Если этого не делать, то, особенно с учетом появления генеративного AI, поток новых специалистов совсем остановится, и через пять лет с проблемами разбираться придется, опять же, нам самим.
Обязательно прочитайте и полную статью, я пропустил много важных идей и тезисов.
Шикарное эссе про то, почему даже с повышением качества и предсказуемости работы AI вам нужно нанимать джунов.
Основная ценность сеньорного инженера – уметь строить надежные, поддерживаемые и понятные системы из меньших блоков. Умение управлять сложной социотехнической системой приходит только с опытом работы в индустрии, методом проб и ошибок и обучения у старших товарищей. Написание простого кода действительно с рядом оговорок можно отдать AI, но вы теряете кучу других важных преимуществ от наличия джунов в команде, включая здоровую групповую динамику, культуру наставничества, да и вообще воронку появления новых сеньоров.
Основной боттлнек индустрии – не развитие джунов, а их найм. Компании не хотят инвестировать в неопытных инженеров, ценность наличия которых в команде сложнее переводится в деньги, чем сеньоров. Именно отсюда и берется постепенное повышение планки найма и невозможность начинающему специалисту найти работу. Повлиять на это могут только сами нанимающие менеджеры, убеждая свое руководство в необходимости найма джунов. Если этого не делать, то, особенно с учетом появления генеративного AI, поток новых специалистов совсем остановится, и через пять лет с проблемами разбираться придется, опять же, нам самим.
Обязательно прочитайте и полную статью, я пропустил много важных идей и тезисов.
stackoverflow.blog
Generative AI is not going to build your engineering team for you - Stack Overflow
Почему data-driven подход неоптимален
👉Данные собираются с тех пользователей, которые есть у вашего продукта сегодня. Если вы расширяете рынок, эти данные могут начать вводить в заблуждение, а не помогать, так как ранние пользователи всегда более лояльны.
👉Получение надежных данных – сложная и долгая задача, замедляющая процесс принятия решений и приводящая к параличу выбора.
👉Когда вы собираете данные с большого количества пользователей, вам приходится их сегментировать тем или иным образом. Сегментация ведет к усреднению пользователей внутри сегмента, а это – к потере важного контекста. Например, внутри большого сегмента может быть скрыт гораздо более ценный сегмент меньшего размера, который вы пропустили, и в итоге не будете оптимизироваться под его нужды.
👉A/B тесты хороши на чувствительных метриках. Из-за этого зачастую более важные метрики, но на которые гораздо сложнее повлиять, вроде долгосрочного ретеншна, обделяются вниманием. Еще хуже обстоит с важными, но трудноизмеряемыми метриками, вроде влияние на бренд.
Вывод из всего этого простой – нужно учиться держать баланс между тем, чтобы полагаться на данные, и тем, чтобы полагаться на собственную интуицию, обученную на общении с пользователями и понимании рынка. Причем чем сильнее конкуренция и чем слабее ваша позиция в ней, тем больше надо полагаться на интуицию, так как она помогает принимать решения гораздо быстрее.
👉Данные собираются с тех пользователей, которые есть у вашего продукта сегодня. Если вы расширяете рынок, эти данные могут начать вводить в заблуждение, а не помогать, так как ранние пользователи всегда более лояльны.
👉Получение надежных данных – сложная и долгая задача, замедляющая процесс принятия решений и приводящая к параличу выбора.
👉Когда вы собираете данные с большого количества пользователей, вам приходится их сегментировать тем или иным образом. Сегментация ведет к усреднению пользователей внутри сегмента, а это – к потере важного контекста. Например, внутри большого сегмента может быть скрыт гораздо более ценный сегмент меньшего размера, который вы пропустили, и в итоге не будете оптимизироваться под его нужды.
👉A/B тесты хороши на чувствительных метриках. Из-за этого зачастую более важные метрики, но на которые гораздо сложнее повлиять, вроде долгосрочного ретеншна, обделяются вниманием. Еще хуже обстоит с важными, но трудноизмеряемыми метриками, вроде влияние на бренд.
Вывод из всего этого простой – нужно учиться держать баланс между тем, чтобы полагаться на данные, и тем, чтобы полагаться на собственную интуицию, обученную на общении с пользователями и понимании рынка. Причем чем сильнее конкуренция и чем слабее ваша позиция в ней, тем больше надо полагаться на интуицию, так как она помогает принимать решения гораздо быстрее.
@andrewchen
Why data-driven product decisions are hard (sometimes impossible)
All the excuses we make when we see data, but why that's sometimes OK
Что почитать тимлиду
Пятница – отличный момент, чтобы выбрать себе новую книгу на выходные. Держите неплохую подборку менеджерских книг, которая выгодно отличается от других тем, что содержит не только самые очевидные рекомендации, например:
👉Dr. James Stanier «Become an Effective Engineering Manager»
👉David Marquet. «Turn the Ship Around»
👉Ю. Гиппенрейтер. «Большая книга общения с ребенком»
Пятница – отличный момент, чтобы выбрать себе новую книгу на выходные. Держите неплохую подборку менеджерских книг, которая выгодно отличается от других тем, что содержит не только самые очевидные рекомендации, например:
👉Dr. James Stanier «Become an Effective Engineering Manager»
👉David Marquet. «Turn the Ship Around»
👉Ю. Гиппенрейтер. «Большая книга общения с ребенком»
Хабр
«Я стал тимлидом и боюсь». Что почитать и зачем
Стресс, связанный с переходом на менеджерскую роль, способен пошатнуть любые, даже самые крепкие нервы. А если ваше решение стать руководителем желанное и осознанное, то вы легко можете загнать себя в...
Обеспечение качества зависит от контекста
У качества может быть много разных определений. То, которое использую я, очень близко к автору статьи. Качество – поведение программы, соответствующее ожиданиям пользователя и нефункциональным требованиям. Но несмотря на то, что это определение общее и для высоконагруженных интернет-сервисов, и для небольших мобильных приложений, и для супер-сложной системы вроде компилятора, подходы к обеспечению качества будут совсем разными.
Вся статья посвящена тому, чтобы показать, что методы обеспечения качества зависят от вашего контекста, и вводит модель, которая помогает рассуждать об этом контексте. Вот на какие параметры предлагается смотреть:
👉Essential domain complexity – неотъемлимая сложность предметной области, в которой работает программа. У интернет-магазина диванов она не очень высокая. У HFT системы, скорее всего, наоборот.
👉Scalability complexity – сложность, создаваемая большим количеством пользователей системы
👉Team maturity – уровень навыков команды и знания предметного контекста
В зависимости от того, попадает ли ваш продукт в ситуацию "low essential domain complexity, high scalability complexity, low team maturity" или "high essential domain complexoty, low scalability complexity, high team maturity", подходы к тому, как обеспечивать качество, будут очень сильно отличаться. Поэтому слепо копировать успешные кейсы других компаний, не понимая, чем их ситуация отличалась от вашей, нельзя.
Помимо этой золотой мысли, в статье выстраивается ментальная модель фидбэк лупов создания продукта с хорошими рассуждениями о том, на каких из них фокусироваться в зависимости от перечисленных выше параметров.
Очень рекомендую статью для тех, кто хочет уложить в понятную модель свои мысли про то, как обеспечивать качество.
У качества может быть много разных определений. То, которое использую я, очень близко к автору статьи. Качество – поведение программы, соответствующее ожиданиям пользователя и нефункциональным требованиям. Но несмотря на то, что это определение общее и для высоконагруженных интернет-сервисов, и для небольших мобильных приложений, и для супер-сложной системы вроде компилятора, подходы к обеспечению качества будут совсем разными.
Вся статья посвящена тому, чтобы показать, что методы обеспечения качества зависят от вашего контекста, и вводит модель, которая помогает рассуждать об этом контексте. Вот на какие параметры предлагается смотреть:
👉Essential domain complexity – неотъемлимая сложность предметной области, в которой работает программа. У интернет-магазина диванов она не очень высокая. У HFT системы, скорее всего, наоборот.
👉Scalability complexity – сложность, создаваемая большим количеством пользователей системы
👉Team maturity – уровень навыков команды и знания предметного контекста
В зависимости от того, попадает ли ваш продукт в ситуацию "low essential domain complexity, high scalability complexity, low team maturity" или "high essential domain complexoty, low scalability complexity, high team maturity", подходы к тому, как обеспечивать качество, будут очень сильно отличаться. Поэтому слепо копировать успешные кейсы других компаний, не понимая, чем их ситуация отличалась от вашей, нельзя.
Помимо этой золотой мысли, в статье выстраивается ментальная модель фидбэк лупов создания продукта с хорошими рассуждениями о том, на каких из них фокусироваться в зависимости от перечисленных выше параметров.
Очень рекомендую статью для тех, кто хочет уложить в понятную модель свои мысли про то, как обеспечивать качество.
Сбор тем и вопросов для большого исследования тимлидов
В прошлом году мы проводили большое исследование тимлидов, где, среди прочего, разбирались с основными навыками руководителей команд, проблемами, с которыми они сталкиваются, способами получения новых знаний и кучей других вещей.
В этом году я вышел из команды проекта, но ребята продолжают делать исследования. Давайте поможем им, и накидаем в комментарии к этому посту вопросы и темы, которые вам было бы интересно разобрать в исследовании. Например:
👉Сколько зарабатывают тимлиды в зависимости от размера команды
👉Что замотивировало тимлидов уйти из разработки в менеджмент
👉Средний срок жизни сотрудника в команде
В прошлом году мы проводили большое исследование тимлидов, где, среди прочего, разбирались с основными навыками руководителей команд, проблемами, с которыми они сталкиваются, способами получения новых знаний и кучей других вещей.
В этом году я вышел из команды проекта, но ребята продолжают делать исследования. Давайте поможем им, и накидаем в комментарии к этому посту вопросы и темы, которые вам было бы интересно разобрать в исследовании. Например:
👉Сколько зарабатывают тимлиды в зависимости от размера команды
👉Что замотивировало тимлидов уйти из разработки в менеджмент
👉Средний срок жизни сотрудника в команде