Про собеседования
За 13 лет работы в IT я прошел десятки собеседований, из которых в 80% случаев я получал оффер, а из-за остальных ни разу не расстроился. Провел, думаю, уже больше пары сотен собеседований. И тут хочу поделиться своими идеями и мыслями про них:
– В большинстве компаний не нужны гении. Гениям, которые не хотят общаться с людьми, понимать ценность своей работы, аргументировать свои идеи и уважать людей вокруг больше подходит фриланс.
– На большинстве собеседований результат понятен в первые 5 минут. Дальше – самообман собеседующего, что он сможет что-то такое разглядеть, чтобы опровергнуть быстрое решение. Сам так делаю постоянно.
– Лучшее, что можно показать на собеседовании – что вам не всё равно то, чем, где и с кем вы занимаетесь. Именно люди, которым не всё равно двигают проекты, повышают качество, внедряют лучшие практики и процессы.
– Лучшие вопросы – те, которые не имеют правильного ответа. Рассуждения и ход мыслей важнее, чем конкретные знания. А конкретные знания можно получить у консультантов или тех же фрилансеров.
– Если при собеседовании в небольшую компанию для вас устраивают собеседование в стиле гугла – скорее всего в компании ещё сами не понимают, кто и зачем им нужен. Не забудьте это выяснить на таком собеседовании:)
За 13 лет работы в IT я прошел десятки собеседований, из которых в 80% случаев я получал оффер, а из-за остальных ни разу не расстроился. Провел, думаю, уже больше пары сотен собеседований. И тут хочу поделиться своими идеями и мыслями про них:
– В большинстве компаний не нужны гении. Гениям, которые не хотят общаться с людьми, понимать ценность своей работы, аргументировать свои идеи и уважать людей вокруг больше подходит фриланс.
– На большинстве собеседований результат понятен в первые 5 минут. Дальше – самообман собеседующего, что он сможет что-то такое разглядеть, чтобы опровергнуть быстрое решение. Сам так делаю постоянно.
– Лучшее, что можно показать на собеседовании – что вам не всё равно то, чем, где и с кем вы занимаетесь. Именно люди, которым не всё равно двигают проекты, повышают качество, внедряют лучшие практики и процессы.
– Лучшие вопросы – те, которые не имеют правильного ответа. Рассуждения и ход мыслей важнее, чем конкретные знания. А конкретные знания можно получить у консультантов или тех же фрилансеров.
– Если при собеседовании в небольшую компанию для вас устраивают собеседование в стиле гугла – скорее всего в компании ещё сами не понимают, кто и зачем им нужен. Не забудьте это выяснить на таком собеседовании:)
🧠 Про когнитивные искажения и быстрый фидбек
История 1. Некто Майкл Нортон провёл такой эксперимент: испытуемых попросили собрать самим мебель. После их спросили, какая мебель стоит дороже – собранная ими или абсолютно такая же, но собранная в ikea? В результате испытуемые были готовы платить больше за ту, которую собрали сами. Это когнитивное искажение так и называется – эффект ikea. Люди непропорционально высоко оценивают те вещи, в которые вложились сами.
История 2. Некто Макс Базерман устраивает для студентов MBA аукцион на 20$ купюру. Условия такие: её получает тот, кто сделает самую большую ставку. Но тот, кто окажется на втором месте будет обязан просто оплатить свою ставку, не получив ничего. Ближе к 20$ остаются 2 «победителя», которые перебивают ставки друг друга и в итоге купюра продаётся дороже своего номинала (рекорд – 204$). Это когнитивное искажение – боязнь потери. Людям важнее избежать потери 20$, чем получить эквивалентный доход.
История 3. Некто (подставьте сюда имя знакомого, ведь вы точно сталкивались с такой ситуацией или были её главным героем) получает большую задачу и идёт её выполнять. Он делает её очень долго, при этом старательно, вкладывает в неё много сил. Он никому не показывает промежуточный результат. И вот спустя месяц (или 2, 4, 6) всё готово. Это может быть огромный текст, сложный интерфейс, красивый дизайн, большое изменение в коде или целый стартап. Окружение начинает находить ошибки, предлагать улучшения, исправления и упрощения, но некто начинает яростно защищать своё творение. «Вы просто не понимаете!», «Вы не в контексте!», говорит он. И его можно понять – ведь он потратил столько времени, которое уже не вернуть. Он подвержен тем же когнитивным искажениям.
Какие выводы?
– Показывайте свою работу окружающим как можно раньше и остальных в команде просите делать так же. Чем меньше вы вложили в результат – тем объективнее вы воспримите фидбек.
– Собирайте фидбек с людей, не вовлеченных в разработку вашего продукта. Иначе получите фидбек, подверженный эффекту ikea
– Научитесь «откатывать» неудачные решения. Это сложно из-за иррационального усиления
История 1. Некто Майкл Нортон провёл такой эксперимент: испытуемых попросили собрать самим мебель. После их спросили, какая мебель стоит дороже – собранная ими или абсолютно такая же, но собранная в ikea? В результате испытуемые были готовы платить больше за ту, которую собрали сами. Это когнитивное искажение так и называется – эффект ikea. Люди непропорционально высоко оценивают те вещи, в которые вложились сами.
История 2. Некто Макс Базерман устраивает для студентов MBA аукцион на 20$ купюру. Условия такие: её получает тот, кто сделает самую большую ставку. Но тот, кто окажется на втором месте будет обязан просто оплатить свою ставку, не получив ничего. Ближе к 20$ остаются 2 «победителя», которые перебивают ставки друг друга и в итоге купюра продаётся дороже своего номинала (рекорд – 204$). Это когнитивное искажение – боязнь потери. Людям важнее избежать потери 20$, чем получить эквивалентный доход.
История 3. Некто (подставьте сюда имя знакомого, ведь вы точно сталкивались с такой ситуацией или были её главным героем) получает большую задачу и идёт её выполнять. Он делает её очень долго, при этом старательно, вкладывает в неё много сил. Он никому не показывает промежуточный результат. И вот спустя месяц (или 2, 4, 6) всё готово. Это может быть огромный текст, сложный интерфейс, красивый дизайн, большое изменение в коде или целый стартап. Окружение начинает находить ошибки, предлагать улучшения, исправления и упрощения, но некто начинает яростно защищать своё творение. «Вы просто не понимаете!», «Вы не в контексте!», говорит он. И его можно понять – ведь он потратил столько времени, которое уже не вернуть. Он подвержен тем же когнитивным искажениям.
Какие выводы?
– Показывайте свою работу окружающим как можно раньше и остальных в команде просите делать так же. Чем меньше вы вложили в результат – тем объективнее вы воспримите фидбек.
– Собирайте фидбек с людей, не вовлеченных в разработку вашего продукта. Иначе получите фидбек, подверженный эффекту ikea
– Научитесь «откатывать» неудачные решения. Это сложно из-за иррационального усиления
Интересно находить каналы, в которых обсуждаются схожие темы – понимаешь, что это не только твоя боль. Одна из таких находок – канал Кнопка Хорошо, в котором Анастасия Борисюк, руководитель проектов из «Актион Технологии» пишет идеально оформленные посты про софтскилы, процессы и общение с коллегами.
Сделал для вас подборку интересных постов:
– Почему так легко отвлечься на другую задачу?
– Плохие руководители
– Раздраженные люди. I часть. Что делать, когда на вас раздражаются?
– Большие письма. 1 часть о культуре переписки
– Синдром отложенной жизни
Сделал для вас подборку интересных постов:
– Почему так легко отвлечься на другую задачу?
– Плохие руководители
– Раздраженные люди. I часть. Что делать, когда на вас раздражаются?
– Большие письма. 1 часть о культуре переписки
– Синдром отложенной жизни
Как заниматься любимым делом?
Всем хочется получать удовольствие от работы. Самый простой способ – заниматься тем, чем хочется. Но часто в наших умах, воспитанных советскими родителями, есть установка: то, что нужно и важно – это не то, что хочется и от чего кайфуешь. Поэтому приходят люди, которые рассказывают нам, чем нужно заниматься, мы это делаем и лишь иногда это оказывается именно тем, что хочется. Делюсь формулой «любимых дел», которую я вывел для себя. В ней 3 слагаемых:
1. Инициативность
Тут всё банально: если вы не расскажете о ваших желаниях, идеях и предложениях – никто о них не узнает. И вероятность того, что вам прилетит задача именно с вашей идеей стремится к 0. Предлагайте и делайте. Но чтобы ваши инициативы чаще слышали и принимали – нужно добавить второй компонент.
2. Ценность для бизнеса
Помните про важность хорошей презентации? Чтобы сделать такую презентацию, нужно понимать, что важно тому, для кого она. А что может быть важнее для бизнеса, если не деньги? Понимать то, как работа превращается в деньги на счету компании – важный софт-скилл для любого сотрудника, в том числе для людей, которые не связаны напрямую с деньгами – разработчики, дизайнеры или, например, hr.
Этот скилл открывает возможность быстрее продавать свои инициативы ведь «нам надо всё переписать на go» звучит менее убедительно, чем «маркетинг говорит, что в конце квартала у нас ожидается в 10 раз больше клиентов. Если не перепишем вон ту часть, то придется платить в 10 раз больше за сервера». Но даже в такой формулировке менеджера, принимающего решение, может остановить последний компонент.
3. Ответственность
Да, есть люди, готовые брать на себя ответственность за чужие ошибки. Но в большинстве случаев проще брать в работу ваши инициативы, если вы сами сможете за них отвечать, особенно в случае неудачных решений (а никто от них не застрахован). Не будьте человеком из поста про я же говорил. Главное правило тут: ответственность не дают, её берут.
Итого: есть желание чем-то заняться? Предложите, обоснуйте ценность для бизнеса и возьмите ответственность за результат.
Всем хочется получать удовольствие от работы. Самый простой способ – заниматься тем, чем хочется. Но часто в наших умах, воспитанных советскими родителями, есть установка: то, что нужно и важно – это не то, что хочется и от чего кайфуешь. Поэтому приходят люди, которые рассказывают нам, чем нужно заниматься, мы это делаем и лишь иногда это оказывается именно тем, что хочется. Делюсь формулой «любимых дел», которую я вывел для себя. В ней 3 слагаемых:
1. Инициативность
Тут всё банально: если вы не расскажете о ваших желаниях, идеях и предложениях – никто о них не узнает. И вероятность того, что вам прилетит задача именно с вашей идеей стремится к 0. Предлагайте и делайте. Но чтобы ваши инициативы чаще слышали и принимали – нужно добавить второй компонент.
2. Ценность для бизнеса
Помните про важность хорошей презентации? Чтобы сделать такую презентацию, нужно понимать, что важно тому, для кого она. А что может быть важнее для бизнеса, если не деньги? Понимать то, как работа превращается в деньги на счету компании – важный софт-скилл для любого сотрудника, в том числе для людей, которые не связаны напрямую с деньгами – разработчики, дизайнеры или, например, hr.
Этот скилл открывает возможность быстрее продавать свои инициативы ведь «нам надо всё переписать на go» звучит менее убедительно, чем «маркетинг говорит, что в конце квартала у нас ожидается в 10 раз больше клиентов. Если не перепишем вон ту часть, то придется платить в 10 раз больше за сервера». Но даже в такой формулировке менеджера, принимающего решение, может остановить последний компонент.
3. Ответственность
Да, есть люди, готовые брать на себя ответственность за чужие ошибки. Но в большинстве случаев проще брать в работу ваши инициативы, если вы сами сможете за них отвечать, особенно в случае неудачных решений (а никто от них не застрахован). Не будьте человеком из поста про я же говорил. Главное правило тут: ответственность не дают, её берут.
Итого: есть желание чем-то заняться? Предложите, обоснуйте ценность для бизнеса и возьмите ответственность за результат.
👍1
Про «синьорность»
– Привет! Нам нужно разместить html-страничку на сайте, можешь сделать?
– Ок, сейчас я создам репозиторий, настрою сборку, подниму сервак, настрою CDN, прогон статического анализатора и тестов в continues integration, настрою деплой и готово. Займет дня 3-4.
К чему это я? Чем больше у людей опыта – тем больше они хотят его применять.
– Опытные разработчики не хотят заливать html файл через ftp, как они делали это в универе, создавая свои первые сайты или делать что-то совсем без кода на тильде. Где вы читали статью или смотрели выступление на конференции о таких задачах?
– Классные дизайнеры не хотят собирать экраны мобильного приложения на стандартных компонентах. Вы видели такое на дрибле?
– Эффективные менеджеры не готовы запускать проекты без джиры, бёрндаун чартов, спринтов и ретроспектив. Какой же это менеджмент?
Всё это – инструменты. Их нужно подбирать под задачу. «Синьорность» специалиста проявляется не в том, что он умеет строить космические корабли, а в том, что он выбирает правильные подходы. Когда ему нужно сделать стол, он не использует чертежи корабля, и стол в итоге не будет сам приземляться на плавающую платформу в океане.
И да, если вы нашли простейший способ решения проблемы, который отвечает всем требованиям, и сделали это за 10 минут – это не обесценивает вас, как специалиста, а скорее наоборот. Возможно вы нашли то самое элегантное решение:
«Simplicity is the keynote of all true elegance» Coco Chanel
– Привет! Нам нужно разместить html-страничку на сайте, можешь сделать?
– Ок, сейчас я создам репозиторий, настрою сборку, подниму сервак, настрою CDN, прогон статического анализатора и тестов в continues integration, настрою деплой и готово. Займет дня 3-4.
К чему это я? Чем больше у людей опыта – тем больше они хотят его применять.
– Опытные разработчики не хотят заливать html файл через ftp, как они делали это в универе, создавая свои первые сайты или делать что-то совсем без кода на тильде. Где вы читали статью или смотрели выступление на конференции о таких задачах?
– Классные дизайнеры не хотят собирать экраны мобильного приложения на стандартных компонентах. Вы видели такое на дрибле?
– Эффективные менеджеры не готовы запускать проекты без джиры, бёрндаун чартов, спринтов и ретроспектив. Какой же это менеджмент?
Всё это – инструменты. Их нужно подбирать под задачу. «Синьорность» специалиста проявляется не в том, что он умеет строить космические корабли, а в том, что он выбирает правильные подходы. Когда ему нужно сделать стол, он не использует чертежи корабля, и стол в итоге не будет сам приземляться на плавающую платформу в океане.
И да, если вы нашли простейший способ решения проблемы, который отвечает всем требованиям, и сделали это за 10 минут – это не обесценивает вас, как специалиста, а скорее наоборот. Возможно вы нашли то самое элегантное решение:
«Simplicity is the keynote of all true elegance» Coco Chanel
📈 Про адаптацию и Gartner's hype cycle
Консалтинговая компания Gartner когда-то сформулировала идею Hype cycle – график зрелости технологий. Это 5 фаз, через которые проходит технология до её адаптации в обществе:
1. Запуск технологии
2. Пик завышенных ожиданий
3. Нижняя точка разочарования
4. Склон просветления
5. Плато производительности
Провел аналогию с мотивацией при адаптации людей на проектах или в компании и кажется, что там всё работает точно так же (ещё и в отношениях график такой, но это тема для другого канала).
– Новички в команде чаще замотивированы сильнее «старичков», но в какой-то момент их мотивация резко идёт вниз.
– Люди склонны завышать ожидания, особенно от того, что плохо понимают. Для них происходит какая-то магия, но потом она рассеивается. Так и в работе над проектом начинает казаться, что всё не так – и проект не тот, и люди не те, и ты не тем занят.
– Дойдя до низа, наконец, начинается просветление. Начинаешь понимать, чем на самом деле вы занимаетесь и куда идёте.
– Первая задача при адаптации новичков: ускорять первые четыре фазы, чтобы они прошли как можно быстрее.
– Вторая: замечать тех, кто скатывается по кривой разочарования, и говорить с ними, занимаясь просветлением.
Консалтинговая компания Gartner когда-то сформулировала идею Hype cycle – график зрелости технологий. Это 5 фаз, через которые проходит технология до её адаптации в обществе:
1. Запуск технологии
2. Пик завышенных ожиданий
3. Нижняя точка разочарования
4. Склон просветления
5. Плато производительности
Провел аналогию с мотивацией при адаптации людей на проектах или в компании и кажется, что там всё работает точно так же (ещё и в отношениях график такой, но это тема для другого канала).
– Новички в команде чаще замотивированы сильнее «старичков», но в какой-то момент их мотивация резко идёт вниз.
– Люди склонны завышать ожидания, особенно от того, что плохо понимают. Для них происходит какая-то магия, но потом она рассеивается. Так и в работе над проектом начинает казаться, что всё не так – и проект не тот, и люди не те, и ты не тем занят.
– Дойдя до низа, наконец, начинается просветление. Начинаешь понимать, чем на самом деле вы занимаетесь и куда идёте.
– Первая задача при адаптации новичков: ускорять первые четыре фазы, чтобы они прошли как можно быстрее.
– Вторая: замечать тех, кто скатывается по кривой разочарования, и говорить с ними, занимаясь просветлением.
Gartner
Gartner Hype Cycle Research Methodology | Gartner
Gartner Hype Cycle methodology offers insights into technology and application evolution to help you manage deployment aligned with business goals.
❤1
💡 Про несостоятельные гипотезы
В продуктовой разработке сейчас все разговоры про гипотезы. Средний продакт или маркетолог по 50 раз в день говорит это слово. Все очень стараются генерировать много гипотез и тестировать их. Но часто тестирование скатывается к подтверждению идеи любой ценой. Помните же про когнитивные искажения? Никто не любит признавать свои гипотезы несостоятельными.
Признавать ошибки в своих суждениях – важный скилл «исследователя» (а любой продакт, менеджер или маркетолог – это исследователь). Но кроме признания ошибок нужно искать пользу в полученных результатах. Более того, иногда опровержение гипотезы может стать более ценным, чем её подтверждение. Просто напомню:
– Слак родился из чата внутри игры Glitch, работы по которой свернули.
– Колумб искал путь в Индию.
– Многие изобретения – это ошибки. Например, микроволновая печь, стикеры, кока-кола, антибиотики.
В общем, признавайте ошибки и ищите в них инсайты.
В продуктовой разработке сейчас все разговоры про гипотезы. Средний продакт или маркетолог по 50 раз в день говорит это слово. Все очень стараются генерировать много гипотез и тестировать их. Но часто тестирование скатывается к подтверждению идеи любой ценой. Помните же про когнитивные искажения? Никто не любит признавать свои гипотезы несостоятельными.
Признавать ошибки в своих суждениях – важный скилл «исследователя» (а любой продакт, менеджер или маркетолог – это исследователь). Но кроме признания ошибок нужно искать пользу в полученных результатах. Более того, иногда опровержение гипотезы может стать более ценным, чем её подтверждение. Просто напомню:
– Слак родился из чата внутри игры Glitch, работы по которой свернули.
– Колумб искал путь в Индию.
– Многие изобретения – это ошибки. Например, микроволновая печь, стикеры, кока-кола, антибиотики.
В общем, признавайте ошибки и ищите в них инсайты.
💹 Количество конкретных задач, как показатель роста
О многих IT-компании ходят легенды, что там не ставят задачи сотрудникам. Например, в Netflix сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс говорил: «I’ve learned over the years that, when you have really good people, you don’t have to baby them. By expecting them to do great things, you can get them to do great things.».
У меня же другая теория. Людям нужны конкретные задачи и цели. Возможно, дело в менталитете и с детства «настоящая» работа воспринимается как схема начальник-подчинённый, где задачи идут сверху вниз. Возможно – из-за нашей системы образования, где людей в университете учат абстрактным теоретическим скилам, а на курсах дают верхнеуровневую практику. Но нигде не учат, как вообще работают компании внутри? Из чего состоит рабочий день разработчика/дизайнера/продакта/менеджера/сейлза? Как они взаимодействуют между собой и чего ожидают друг от друга?
Так вот, из-за этих установок нужно ставить конкретные задачи, но постепенно бороться с такой моделью, чтобы в итоге задачи и цели поднимались «снизу вверх». А любой сотрудник может оценивать свой рост в компании, отслеживая простую метрику: количество конкретных задач, которые ему ставят. Вижу такие ступени роста:
1. Вам ставят конкретные задачи. Они помогают понять, что тут вообще происходит и куда они ведут
2. Вам ставят верхнеуровневые цели. Вы можете сами придумать, как их достичь
3. Вы вместе с менеджером ставите свои верхнеуровневые цели.
4. Вы сами ставите верхнеуровневые цели. Вы достаточно разобрались в том, за что вам платят деньги и понимаете, в какую сторону идти.
5. Вы возвращаетесь на 1 шаг, но уже в другой роли.
Работая над такой схемой и «двигая» сотрудников по ступеням (или ожидая, что они продвинутся сами) рождается культура: «Культура компании это, как принимаются решения в отсутствии руководства.»
А вы сейчас на каком шаге?
О многих IT-компании ходят легенды, что там не ставят задачи сотрудникам. Например, в Netflix сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс говорил: «I’ve learned over the years that, when you have really good people, you don’t have to baby them. By expecting them to do great things, you can get them to do great things.».
У меня же другая теория. Людям нужны конкретные задачи и цели. Возможно, дело в менталитете и с детства «настоящая» работа воспринимается как схема начальник-подчинённый, где задачи идут сверху вниз. Возможно – из-за нашей системы образования, где людей в университете учат абстрактным теоретическим скилам, а на курсах дают верхнеуровневую практику. Но нигде не учат, как вообще работают компании внутри? Из чего состоит рабочий день разработчика/дизайнера/продакта/менеджера/сейлза? Как они взаимодействуют между собой и чего ожидают друг от друга?
Так вот, из-за этих установок нужно ставить конкретные задачи, но постепенно бороться с такой моделью, чтобы в итоге задачи и цели поднимались «снизу вверх». А любой сотрудник может оценивать свой рост в компании, отслеживая простую метрику: количество конкретных задач, которые ему ставят. Вижу такие ступени роста:
1. Вам ставят конкретные задачи. Они помогают понять, что тут вообще происходит и куда они ведут
2. Вам ставят верхнеуровневые цели. Вы можете сами придумать, как их достичь
3. Вы вместе с менеджером ставите свои верхнеуровневые цели.
4. Вы сами ставите верхнеуровневые цели. Вы достаточно разобрались в том, за что вам платят деньги и понимаете, в какую сторону идти.
5. Вы возвращаетесь на 1 шаг, но уже в другой роли.
Работая над такой схемой и «двигая» сотрудников по ступеням (или ожидая, что они продвинутся сами) рождается культура: «Культура компании это, как принимаются решения в отсутствии руководства.»
А вы сейчас на каком шаге?
🪤 Метрики-ловушки
Люди любят дофамин – для них это награда за проделанные труды. Дофамин действует на нас, как наркотик. Чем больше его получаешь – тем больше хочешь делать то, за что ты его получил.
Люди ленивые, поэтому научились получать дешевый дофамин: есть сладкое, смотреть порно, залипать в инстаграм. В работе тоже легко скатиться к дешевому дофамину. Для этого достаточно отключить критическое мышление в стиле «а тем ли я занят?», найти пару метрик, на которые можно смотреть и радоваться проделанной работе.
Это – метрики-ловушки, т.к. в моменте они доставляют удовольствие (как сыр в мышеловке), но на долгом промежутке времени негативно влияют на результат (как сладкое или порно). Достаточно сделать нелогичное суждение – и вот вы уже в ловушке:
– Я долго работал, я молодец. А тем ли я занимался? Нужно ли дальше работать долго, а не работать на результат?
– У нас нет техдолга, значит у нас классный продукт. А может мы слишком много наводим порядок, из-за этого двигаемся медленнее, чем могли бы?
– Команда выросла в 3 раза за последний год, мы растём! А начали ли делать в 3 раза больше?
– Мы привлекли миллион пользователей в наш продукт, заработаем много денег! А они окупятся?
– Я не повышаю зарплату подчиненным до уровня рынка, экономлю деньги компании – я хороший менеджер. А оправдает ли себя эта экономия, когда они уйдут?
Не ищите легкий дофамин. Ищите метрики-ловушки, которые вы используете, и меняйте способ мышления.
Люди любят дофамин – для них это награда за проделанные труды. Дофамин действует на нас, как наркотик. Чем больше его получаешь – тем больше хочешь делать то, за что ты его получил.
Люди ленивые, поэтому научились получать дешевый дофамин: есть сладкое, смотреть порно, залипать в инстаграм. В работе тоже легко скатиться к дешевому дофамину. Для этого достаточно отключить критическое мышление в стиле «а тем ли я занят?», найти пару метрик, на которые можно смотреть и радоваться проделанной работе.
Это – метрики-ловушки, т.к. в моменте они доставляют удовольствие (как сыр в мышеловке), но на долгом промежутке времени негативно влияют на результат (как сладкое или порно). Достаточно сделать нелогичное суждение – и вот вы уже в ловушке:
– Я долго работал, я молодец. А тем ли я занимался? Нужно ли дальше работать долго, а не работать на результат?
– У нас нет техдолга, значит у нас классный продукт. А может мы слишком много наводим порядок, из-за этого двигаемся медленнее, чем могли бы?
– Команда выросла в 3 раза за последний год, мы растём! А начали ли делать в 3 раза больше?
– Мы привлекли миллион пользователей в наш продукт, заработаем много денег! А они окупятся?
– Я не повышаю зарплату подчиненным до уровня рынка, экономлю деньги компании – я хороший менеджер. А оправдает ли себя эта экономия, когда они уйдут?
Не ищите легкий дофамин. Ищите метрики-ловушки, которые вы используете, и меняйте способ мышления.
📚 Теория или практика
Что важнее? Извечный вопрос с очевидным ответом. Рассуждаю я так:
Чтобы приблизиться к результату у нас есть 2 варианта:
1. Уходить в теорию и повышать вероятность успеха. Читать книжки и статьи, анализировать чужие ошибки, узнавать best practices. Чем больше узнаем – тем выше вероятность успеха.
2. Увеличивать количество попыток, просто постоянно пробуя.
Что быстрее приведёт к положительным результатам? Бесконечно прокачивая вероятность успеха, она всё равно не достигнет единицы. И даже в этом случае 1 × 0 = 0. Значит, рано или поздно придётся начать действовать, так зачем ждать? Только представьте себе альтернативную вселенную, где люди сначала учатся чему-то лет 5-6, и только потом применяют свои знания в реальных задачах. Или другую, где они проходят различные онлайн курсы, но закончив – находят пробелы в своих знаниях и записываются на следующий курс, так и не начав делать что-то реальное. Бред же!
С другой стороны, даже если вероятность успеха, допустим 0.01, то через сотню-другую попыток у нас будет результат. Более того, постоянно пробуя, мы узнаем что-то новое. То есть постоянная практика прокачивает и теорию, а в обратную сторону это не работает.
Главное не увлечься и не начать рубить дерево тупым топором. Конечно, рано или поздно оно рухнет, но не проще ли заточить? Или можно продолжать рубить его, так и не узнав, что в соседнем лесу уже давно используют электропилу.
Итого: быстрее и больше пробуйте. Не пытайтесь сразу узнать всё – это невозможно. Анализируйте, что получается хорошо или плохо и прокачивайте нужные знания, а не «на всякий случай». И не забывайте смотреть по сторонам и общаться с другими лесниками.
Что важнее? Извечный вопрос с очевидным ответом. Рассуждаю я так:
результат = вероятность успеха × количество попыток
Чтобы приблизиться к результату у нас есть 2 варианта:
1. Уходить в теорию и повышать вероятность успеха. Читать книжки и статьи, анализировать чужие ошибки, узнавать best practices. Чем больше узнаем – тем выше вероятность успеха.
2. Увеличивать количество попыток, просто постоянно пробуя.
Что быстрее приведёт к положительным результатам? Бесконечно прокачивая вероятность успеха, она всё равно не достигнет единицы. И даже в этом случае 1 × 0 = 0. Значит, рано или поздно придётся начать действовать, так зачем ждать? Только представьте себе альтернативную вселенную, где люди сначала учатся чему-то лет 5-6, и только потом применяют свои знания в реальных задачах. Или другую, где они проходят различные онлайн курсы, но закончив – находят пробелы в своих знаниях и записываются на следующий курс, так и не начав делать что-то реальное. Бред же!
С другой стороны, даже если вероятность успеха, допустим 0.01, то через сотню-другую попыток у нас будет результат. Более того, постоянно пробуя, мы узнаем что-то новое. То есть постоянная практика прокачивает и теорию, а в обратную сторону это не работает.
Главное не увлечься и не начать рубить дерево тупым топором. Конечно, рано или поздно оно рухнет, но не проще ли заточить? Или можно продолжать рубить его, так и не узнав, что в соседнем лесу уже давно используют электропилу.
Итого: быстрее и больше пробуйте. Не пытайтесь сразу узнать всё – это невозможно. Анализируйте, что получается хорошо или плохо и прокачивайте нужные знания, а не «на всякий случай». И не забывайте смотреть по сторонам и общаться с другими лесниками.
🎯 Как делать больше?
В создании чего-то нового (написании поста в блог, дизайне экрана, разработке приложения) есть ловушка: «создатель» думает о том, как его продукт будет потребять пользователь, и создаёт в том же порядке.
Как читают статью? Сверху вниз, слева направо – так и будем писать. На экране сначала показывается хедер и меню, а потом основной контент – так в фигму и добавим. Путь пользователя в нашем приложении начинается с регистрации и авторизации – вот с этого и начнём.
С таким подходом проекты чаще затягиваются: у вас нет возможности быстро получить фидбек о работе «самого главного», нет возможности в любой момент остановиться и выкатить то, что есть (а это главный инструмент против перфекционизма и как следствие – прокрастинации). Никому не нужны красиво нарисованные, свёрстанные и протестированные экраны авторизации и регистрации, если после этого пользователь ничего не увидит (если только вашей целью не было протестировать именно эти экраны или онбординг). Не нужно красивое введение в пустую статью. Не нужна красивая архитектура бекенда, которая ничего не умеет.
А как лучше? Выделить место под второстепенные вещи – просто поставить прямоугольник вместо хедера, «захардкодить» вошедшего пользователя, отбить введение парой переносов строк и начать с главной мысли статьи. При создании лендинга – сначала добавить кнопку и аналитику, а потом всю красоту вокруг. Что главное увидит пользователь на экране? Какие выводы должен сделать читатель? Какой call to action на лендинге? В чём главный JTBD продукта?
В каждый момент времени в любом проекте или задаче есть что-то главное, что принесёт 80% всей ценности и куча мелочей, которые принесут только 20% результата. Всегда велик соблазн начать именно с мелочей – они понятнее и проще. Не делайте так. Лучше делайте вот так:
1. Выделите must-have. Что самое главное и полезное в проекте?
2. Поставьте дедлайн. Хотя бы на первую версию
3. Сделайте самое главное
4. Если есть время – добавьте деталей вокруг.
5. Запланируйте следующий проект. Переходите на 1 шаг
В общем, не занимайтесь никому не нужной фигней. Занимайтесь главным. ⠀
В создании чего-то нового (написании поста в блог, дизайне экрана, разработке приложения) есть ловушка: «создатель» думает о том, как его продукт будет потребять пользователь, и создаёт в том же порядке.
Как читают статью? Сверху вниз, слева направо – так и будем писать. На экране сначала показывается хедер и меню, а потом основной контент – так в фигму и добавим. Путь пользователя в нашем приложении начинается с регистрации и авторизации – вот с этого и начнём.
С таким подходом проекты чаще затягиваются: у вас нет возможности быстро получить фидбек о работе «самого главного», нет возможности в любой момент остановиться и выкатить то, что есть (а это главный инструмент против перфекционизма и как следствие – прокрастинации). Никому не нужны красиво нарисованные, свёрстанные и протестированные экраны авторизации и регистрации, если после этого пользователь ничего не увидит (если только вашей целью не было протестировать именно эти экраны или онбординг). Не нужно красивое введение в пустую статью. Не нужна красивая архитектура бекенда, которая ничего не умеет.
А как лучше? Выделить место под второстепенные вещи – просто поставить прямоугольник вместо хедера, «захардкодить» вошедшего пользователя, отбить введение парой переносов строк и начать с главной мысли статьи. При создании лендинга – сначала добавить кнопку и аналитику, а потом всю красоту вокруг. Что главное увидит пользователь на экране? Какие выводы должен сделать читатель? Какой call to action на лендинге? В чём главный JTBD продукта?
В каждый момент времени в любом проекте или задаче есть что-то главное, что принесёт 80% всей ценности и куча мелочей, которые принесут только 20% результата. Всегда велик соблазн начать именно с мелочей – они понятнее и проще. Не делайте так. Лучше делайте вот так:
1. Выделите must-have. Что самое главное и полезное в проекте?
2. Поставьте дедлайн. Хотя бы на первую версию
3. Сделайте самое главное
4. Если есть время – добавьте деталей вокруг.
5. Запланируйте следующий проект. Переходите на 1 шаг
В общем, не занимайтесь никому не нужной фигней. Занимайтесь главным. ⠀
Про хаос
В какой-то момент осознал, что стал спокойнее и счастливее в работе, потому что перестал ожидать полного порядка и работающих как часы систем. И вам советую: смиритесь с тем, что вокруг хаос и вы не сможете его побороть. Любое принятое вами решение будет компромиссом и не будет работать в 100% случаев. Всегда закладывайте в ваши планы то, что что-то пойдёт не так, а решение будет не оптимальным.
– Люди, которым вы делегируете задачи неправильно вас поймут и сделают не так, как вы ожидаете
– Найдётся тот, кому будет неудобно использовать придуманный вами бизнес-процесс и он будет его обходить
– Придуманные вами абстракции для нового сложного проекта рано или поздно потекут
– Любые выделенные вами ресурсы будут использоваться не на 100% (люди, деньги, сервера, время) – всегда можно будет сделать лучше
– Пока вы будете делать идеальную фичу или продукт – она станет не актуальна или вас обгонит конкурент
В общем, старайтесь создавать системы, приручать хаос и уменьшать энтропию, но для душевного спокойствия не ожидайте, что созданные системы будут работать как часы в 100% случаев.
В какой-то момент осознал, что стал спокойнее и счастливее в работе, потому что перестал ожидать полного порядка и работающих как часы систем. И вам советую: смиритесь с тем, что вокруг хаос и вы не сможете его побороть. Любое принятое вами решение будет компромиссом и не будет работать в 100% случаев. Всегда закладывайте в ваши планы то, что что-то пойдёт не так, а решение будет не оптимальным.
– Люди, которым вы делегируете задачи неправильно вас поймут и сделают не так, как вы ожидаете
– Найдётся тот, кому будет неудобно использовать придуманный вами бизнес-процесс и он будет его обходить
– Придуманные вами абстракции для нового сложного проекта рано или поздно потекут
– Любые выделенные вами ресурсы будут использоваться не на 100% (люди, деньги, сервера, время) – всегда можно будет сделать лучше
– Пока вы будете делать идеальную фичу или продукт – она станет не актуальна или вас обгонит конкурент
В общем, старайтесь создавать системы, приручать хаос и уменьшать энтропию, но для душевного спокойствия не ожидайте, что созданные системы будут работать как часы в 100% случаев.
Как ставить задачи джунам?
Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.
Я как-то писал, что рост сотрудников можно оценивать по количеству конкретных задач, которые им ставят. Недавно я понял, что кроме метрики количества задач, есть ещё обратная – количество принимаемых решений. Так джуну ставят много четких указаний и он принимает мало решений, а чем «синьорней» он становится – тем больше он принимает решений сам и меньше выполняет конкретных задач, причем чем дальше – тем выше качество этих принимаемых решений. Он может сам находить проблемы, реализовывать решения (или раздавать задачи другим).
С такой моделью в голове ответить на вопрос из заголовка можно уже немного иначе: задачи джуну нужно ставить так, чтобы он быстрее начал сам принимать решения, причем чтобы качество этих решений вас устраивало. Как помочь?
- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати,
- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из
- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения, и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться.
А есть ещё мнения по этому поводу?
Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать.
Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.
Я как-то писал, что рост сотрудников можно оценивать по количеству конкретных задач, которые им ставят. Недавно я понял, что кроме метрики количества задач, есть ещё обратная – количество принимаемых решений. Так джуну ставят много четких указаний и он принимает мало решений, а чем «синьорней» он становится – тем больше он принимает решений сам и меньше выполняет конкретных задач, причем чем дальше – тем выше качество этих принимаемых решений. Он может сам находить проблемы, реализовывать решения (или раздавать задачи другим).
С такой моделью в голове ответить на вопрос из заголовка можно уже немного иначе: задачи джуну нужно ставить так, чтобы он быстрее начал сам принимать решения, причем чтобы качество этих решений вас устраивало. Как помочь?
- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати,
explain analyze до/после поможет понять детали»- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из
users в availableUsers» можно написать тоже самое + добавить «Кстати, про именование можешь посмотреть классный доклад или почитать мини-книжку Naming Things!».- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения, и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться.
А есть ещё мнения по этому поводу?
Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать.
Telegram
Saturday Night Hack
💹 Количество конкретных задач, как показатель роста
О многих IT-компании ходят легенды, что там не ставят задачи сотрудникам. Например, в Netflix сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс…
О многих IT-компании ходят легенды, что там не ставят задачи сотрудникам. Например, в Netflix сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс…
No gos
Часто релизы и тесты новых продуктов/фич/процессов тормозятся не из-за их основной гипотезы, а наоборот – из-за редких корнер-кейсов или добавления «приятных мелочей». Обсуждения, как их разрулить затягиваются, приходится привлекать всё больше людей, а решения начинают раскрывать всё больше технического и дизайнерского долга в продуктах, а значит увеличивают время разработки «хорошего решения».
Мы в работе стараемся не стопориться в таких ситуациях, а просто явно договариваемся о том, что мы не будем делать. Например:
– Не обрабатывать корнер-кейс для пользователя, а просто показывать ошибку и собирать в аналитику информацию, как часто она возникает
– Не добавлять в интерфейс возможность что-то изменить, но добавлять возможность обратиться в саппорт и попросить это сделать
– Не делать приятные мелочи обязательной частью задачи, а добавлять их только если успеваем.
Не могу представить себя лет 7 назад, мыслящим так же: «Это что, мы умышленно неработающее приложение выкатим на пользователя!?». Но оказалось, что так живётся намного лучше: продукты эволюционируют быстрее, данных собирается больше, а митингов, где мы решаем проблемы для 0.001% наших пользователей стало меньше. А часть идей всё равно приходится откатывать, так что корнер кейсы вообще не приходится решать.
Главное в таком подходе – фиксировать «долги» и обязательно к ним возвращаться. Вот тут мы часто обжигались – некоторые проблемы были понятны ещё на этапе разработки, но нигде не фиксировались и потом выстреливали в колено.
В общем, заранее договориться о том, что вы не будете делать – отличный способ ускорить разработку. А в книге Shape Up от Basecamp авторы вообще предлагают делать no gos частью описания любого проекта.
Часто релизы и тесты новых продуктов/фич/процессов тормозятся не из-за их основной гипотезы, а наоборот – из-за редких корнер-кейсов или добавления «приятных мелочей». Обсуждения, как их разрулить затягиваются, приходится привлекать всё больше людей, а решения начинают раскрывать всё больше технического и дизайнерского долга в продуктах, а значит увеличивают время разработки «хорошего решения».
Мы в работе стараемся не стопориться в таких ситуациях, а просто явно договариваемся о том, что мы не будем делать. Например:
– Не обрабатывать корнер-кейс для пользователя, а просто показывать ошибку и собирать в аналитику информацию, как часто она возникает
– Не добавлять в интерфейс возможность что-то изменить, но добавлять возможность обратиться в саппорт и попросить это сделать
– Не делать приятные мелочи обязательной частью задачи, а добавлять их только если успеваем.
Не могу представить себя лет 7 назад, мыслящим так же: «Это что, мы умышленно неработающее приложение выкатим на пользователя!?». Но оказалось, что так живётся намного лучше: продукты эволюционируют быстрее, данных собирается больше, а митингов, где мы решаем проблемы для 0.001% наших пользователей стало меньше. А часть идей всё равно приходится откатывать, так что корнер кейсы вообще не приходится решать.
Главное в таком подходе – фиксировать «долги» и обязательно к ним возвращаться. Вот тут мы часто обжигались – некоторые проблемы были понятны ещё на этапе разработки, но нигде не фиксировались и потом выстреливали в колено.
В общем, заранее договориться о том, что вы не будете делать – отличный способ ускорить разработку. А в книге Shape Up от Basecamp авторы вообще предлагают делать no gos частью описания любого проекта.
Basecamp
Shape Up: Stop Running in Circles and Ship Work that Matters
Shape Up will help you break free of “best practices” that aren’t really working, think deeper about the right problems, and start shipping meaningful projects your team can celebrate.
Все статьи про проведение 1:1 обычно написаны менеджерами для менеджеров. Решил исправить это и написал на хабр гайд про проведение 1:1 для разработчиков (который на самом деле подойдёт для всех).
Если правильно готовить 1:1 – это отличный инструмент вашего роста и построения комфортной среды на работе, пользуйтесь им.
Если правильно готовить 1:1 – это отличный инструмент вашего роста и построения комфортной среды на работе, пользуйтесь им.
Хабр
Как проводить 1:1: гайд для разработчиков, а не менеджеров
Если вы пересекаетесь с вашим линейным менеджером только тогда, когда нужно подписать отпуск или приходите к нему с оффером от другой компании, то что-то идёт не так. Чтобы получать качественный...
Про объяснения
Чем больше наблюдаю за общением людей, тем больше замечаю, как они не понимают друг друга. Очевидно, КПД любых коммуникаций всегда меньше 100%, ведь знания не копируются через
Вообще, 100% КПД коммуникаций – это главное достоинство фуллстеков (T-Shape/E-Shape/etc), ведь у них коммуникации происходят внутри головы. Но обычно нужно работать с командой, а значит стоит задуматься о качестве.
Я, конечно, не смогу на 100% передать свои идеи, но попробую накидать, о чем можно задуматься:
А не рассказываю ли я это для себя?
Из-за ошибки Хайндсайта («эффект послезнания») будет казаться, что вы рассказываете очевидные вещи и будете их пропускать. Но очевидны ли они собеседнику? Лучше уточнить.
А в чем цель?
Я хочу кому-то что-то рассказать. Но зачем? Рассказать о своём продукте можно:
– Клиенту, чтобы он вам заплатил. Объяснить нужно ценность продукта для него
– Инвестору, чтобы он дал вам денег. Нужно объяснить, почему продукт приумножит его вложения
– Потенциальному сотруднику, чтобы он пришел к вам работать. Объяснить нужно сложность/ интересность задач и крутость команды.
Получается, что тема одна, а объяснений в зависимости от цели – много. Так вот, задумавшись о цели станет понятнее, что же написать в комментарии к коду, описании к пулл-реквесту или в задаче в джире.
А какой контекст?
С кем мы общаемся? О чем они знают? О чем могут не знать? А достаточно ли ответов на вопросы «что?» или «как?», может стоит больше рассказать «зачем?». Будут нас слушать или читать? В какой обстановке? Сколько у них времени? Ответы на эти вопросы направят объяснение в нужную сторону, определят его глубину и придадут ему нужную форму.
А не хочу ли я показаться слишком умным?
Всегда в объяснение напрашивается какая-нибудь отсылочка или термин. Но они только увеличивают объем данных. Количество сущностей и абстракций растёт, кошелёк Миллера переполняется, а КПД объяснения падает.
Но может ваша цель именно в расширении контекста и вам, например, хочется людям рассказать про ошибку Хайндсайта или кошелёк Миллера в посте про коммуникации?
А что почитать по теме?
– Пост Евгения Казначеева про теорию документаций – тут можно узнать про разные типы документаций и их цели.
– Книгу Ильяхова «Ясно, понятно» – тут вся книга пропитана идеей того, что нужно думать о слушателе/читателе, контексте и целях с тысячами примеров.
P.S. Наткнулся на отличную идею того, как можно оценить уровень коммуникаций и взаимодействий в команде, работающей над продуктом:
«The degree to which a system feels human and goal-oriented in its interactions reflects how well its creators interacted with each other.» Erika Hall, Conversational Design
Чем больше наблюдаю за общением людей, тем больше замечаю, как они не понимают друг друга. Очевидно, КПД любых коммуникаций всегда меньше 100%, ведь знания не копируются через
cmd+c/cmd+v из головы в голову. Но часто люди просто игнорируют этот факт и не задумываются о качестве своих объяснений и не пытаются их оценить и улучшить. Кажется, что самого факта объяснения достаточно, чтобы их поняли. Вообще, 100% КПД коммуникаций – это главное достоинство фуллстеков (T-Shape/E-Shape/etc), ведь у них коммуникации происходят внутри головы. Но обычно нужно работать с командой, а значит стоит задуматься о качестве.
Я, конечно, не смогу на 100% передать свои идеи, но попробую накидать, о чем можно задуматься:
А не рассказываю ли я это для себя?
Из-за ошибки Хайндсайта («эффект послезнания») будет казаться, что вы рассказываете очевидные вещи и будете их пропускать. Но очевидны ли они собеседнику? Лучше уточнить.
А в чем цель?
Я хочу кому-то что-то рассказать. Но зачем? Рассказать о своём продукте можно:
– Клиенту, чтобы он вам заплатил. Объяснить нужно ценность продукта для него
– Инвестору, чтобы он дал вам денег. Нужно объяснить, почему продукт приумножит его вложения
– Потенциальному сотруднику, чтобы он пришел к вам работать. Объяснить нужно сложность/ интересность задач и крутость команды.
Получается, что тема одна, а объяснений в зависимости от цели – много. Так вот, задумавшись о цели станет понятнее, что же написать в комментарии к коду, описании к пулл-реквесту или в задаче в джире.
А какой контекст?
С кем мы общаемся? О чем они знают? О чем могут не знать? А достаточно ли ответов на вопросы «что?» или «как?», может стоит больше рассказать «зачем?». Будут нас слушать или читать? В какой обстановке? Сколько у них времени? Ответы на эти вопросы направят объяснение в нужную сторону, определят его глубину и придадут ему нужную форму.
А не хочу ли я показаться слишком умным?
Всегда в объяснение напрашивается какая-нибудь отсылочка или термин. Но они только увеличивают объем данных. Количество сущностей и абстракций растёт, кошелёк Миллера переполняется, а КПД объяснения падает.
Но может ваша цель именно в расширении контекста и вам, например, хочется людям рассказать про ошибку Хайндсайта или кошелёк Миллера в посте про коммуникации?
А что почитать по теме?
– Пост Евгения Казначеева про теорию документаций – тут можно узнать про разные типы документаций и их цели.
– Книгу Ильяхова «Ясно, понятно» – тут вся книга пропитана идеей того, что нужно думать о слушателе/читателе, контексте и целях с тысячами примеров.
P.S. Наткнулся на отличную идею того, как можно оценить уровень коммуникаций и взаимодействий в команде, работающей над продуктом:
«The degree to which a system feels human and goal-oriented in its interactions reflects how well its creators interacted with each other.» Erika Hall, Conversational Design
Про KPI, метрики и эффект наблюдателя
Эффект наблюдателя – проблема из физики. Если коротко, то почти все физические величины немного изменяются, если за ними наблюдать. Самый простой пример – сложно измерить давление в колесе, не изменив его. При подключении манометра часть воздуха выйдет. Невозможно увидеть частицу, не осветив её, а этим мы изменим её состояние.
Этот же эффект распространяется на живых существ и людей: животные в дикой природе ведут себя иначе, если понимают, что за ними наблюдают. Врачи чаще моют руки, когда знают, что это измеряется.
Постановки KPI – пример использования этого эффекта. Кажется, это позволяет нам упростить управление: обкладываем сотрудников со всех сторон метриками, дашбордами и планами на месяц, запускаем команду биг дата для измерения вовлеченности и увольняем всех неугодных (ну простите, не удержался). Но не всё так просто.
Во-первых, часто с помощью метрик мы лишь пытаемся подтвердить свою гипотезу. Типа, «так-так, кажется Василий не вовлечен. Давайте посмотрим, сколько сообщений в слак он отправляет? Вооот, я же говорил! Всего по 100 в день, а медиана по компании – 200!». Привет, confirmation bias, который помог нам подтвердить наши слова (и возможно пропустить по дороге пару опровержений). Но в реальности мы нашли лишь отклонение от нормы, но не причину. Возможно, Вася просто обладает редким навыком в одном сообщении сразу и здороваться, и свой вопрос писать. Это же не делает его не вовлеченным?
Во-вторых, конечно, из-за эффекта наблюдателя я, абстрактный не вовлеченный сотрудник, буду вести себя не так, как без надзора и стану ориентироваться на поставленные KPI. Но если вдруг сроки будут гореть, от результата будет зависеть моя премия, а в конце месяца мне нужно будет платить ипотеку – я буду придумывать механизмы, как эти метрики поднять любым способом. А на другие важные метрики, от которых явно не зависит моя судьба, я буду забивать (привет, законы Кэмпбелла и Гудхарта). А всё ради заветного бонуса. Причем в той или иной степени этому эффекту будут подвержены все, а степень эта будет зависеть от уровня осознанности, личных целей и размера платежа за ипотеку.
Основная мысль: метрики, дашборды и KPI – это упрощение, абстракция над любыми процессами и результатами. Они упрощают и ускоряют понимание общей картины, но скрывают детали. А значит:
– Они должны обозначать вектор, в котором нужно двигаться, а не быть целью;
– Они должны быть инструментом для поиска инсайтов и аномалий, а не инструментом для принятия решений. А в причинах этих аномалий нужно идти и разбираться.
Что почитать по теме?
– Морейнис про законы Кэмпбелла и Гудхарта
– Farnam Street про Observer effect
– Farnam Street про Confirmation bias
UPD: в комментариях напомнили ещё про джедайские техники:
– Дорофеев про Черный закон метрик
Эффект наблюдателя – проблема из физики. Если коротко, то почти все физические величины немного изменяются, если за ними наблюдать. Самый простой пример – сложно измерить давление в колесе, не изменив его. При подключении манометра часть воздуха выйдет. Невозможно увидеть частицу, не осветив её, а этим мы изменим её состояние.
Этот же эффект распространяется на живых существ и людей: животные в дикой природе ведут себя иначе, если понимают, что за ними наблюдают. Врачи чаще моют руки, когда знают, что это измеряется.
Постановки KPI – пример использования этого эффекта. Кажется, это позволяет нам упростить управление: обкладываем сотрудников со всех сторон метриками, дашбордами и планами на месяц, запускаем команду биг дата для измерения вовлеченности и увольняем всех неугодных (ну простите, не удержался). Но не всё так просто.
Во-первых, часто с помощью метрик мы лишь пытаемся подтвердить свою гипотезу. Типа, «так-так, кажется Василий не вовлечен. Давайте посмотрим, сколько сообщений в слак он отправляет? Вооот, я же говорил! Всего по 100 в день, а медиана по компании – 200!». Привет, confirmation bias, который помог нам подтвердить наши слова (и возможно пропустить по дороге пару опровержений). Но в реальности мы нашли лишь отклонение от нормы, но не причину. Возможно, Вася просто обладает редким навыком в одном сообщении сразу и здороваться, и свой вопрос писать. Это же не делает его не вовлеченным?
Во-вторых, конечно, из-за эффекта наблюдателя я, абстрактный не вовлеченный сотрудник, буду вести себя не так, как без надзора и стану ориентироваться на поставленные KPI. Но если вдруг сроки будут гореть, от результата будет зависеть моя премия, а в конце месяца мне нужно будет платить ипотеку – я буду придумывать механизмы, как эти метрики поднять любым способом. А на другие важные метрики, от которых явно не зависит моя судьба, я буду забивать (привет, законы Кэмпбелла и Гудхарта). А всё ради заветного бонуса. Причем в той или иной степени этому эффекту будут подвержены все, а степень эта будет зависеть от уровня осознанности, личных целей и размера платежа за ипотеку.
Основная мысль: метрики, дашборды и KPI – это упрощение, абстракция над любыми процессами и результатами. Они упрощают и ускоряют понимание общей картины, но скрывают детали. А значит:
– Они должны обозначать вектор, в котором нужно двигаться, а не быть целью;
– Они должны быть инструментом для поиска инсайтов и аномалий, а не инструментом для принятия решений. А в причинах этих аномалий нужно идти и разбираться.
Что почитать по теме?
– Морейнис про законы Кэмпбелла и Гудхарта
– Farnam Street про Observer effect
– Farnam Street про Confirmation bias
UPD: в комментариях напомнили ещё про джедайские техники:
– Дорофеев про Черный закон метрик
Что выбрать: личную или командную выгоду?
Работая в команде часто приходится стоять перед выбором, как решить какую-то задачу. Пойти и быстро сделать самому, потому что так проще или научить кого-то, потратить больше сил и времени и уменьшить базфактор? Написать код, чтобы он просто работал или написать его так, чтобы его ещё можно было читать и поддерживать? Молча сделать, как сказали или разобраться в том, что на самом деле от нас хотели и предложить решение лучше?
Чаще всего мы выбираем между быстрой, большой личной выгодой (экономим силы/время) и долгосрочной небольшой выгодой для всех. Очень похоже на дилемму заключенного где сотрудничество – это решение в пользу команды, предательство – решение в личную пользу. За исключением того, что тут никто никого реально не предает (если, конечно, не забывает писать тесты и обновлять документацию). Напомню, суть дилеммы – это выбор сотрудничать или предавать в ситуации:
- Если Вася и Петя сотрудничают – они получают некоторую выгоду
- Если Вася предает Петю, а Петя сотрудничает с Васей, то Вася получает максимальную выгоду, а Петя ничего не получает. И наоборот
- Если они предают друг друга – оба получают наименьшую выгоду.
В 1984 году Роберт Аксельрод в книге «The Evolution of Cooperation» описал различные тактики принятия решения в повторяющейся дилемме заключенного (когда Вася помнит, как вел себя Петя до этого и принимает своё решение основываясь на этом). Это были изначально враждебные или дружелюбные алгоритмы; жадные или щедрые; мстительные и прощающие. В эксперименте стратегии сталкивали друг с другом и смотрели, какие стратегии зарабатывают больше очков. В итоге лидировали:
- Добрые, которые никогда не предают первыми
- Мстительные. Всегда сотрудничать это плохой выбор, т.к. рано или поздно попадётся «злая» стратегия, которая будет этим пользоваться. Но в то же время они должны быть прощающими, т.к. постоянная месть может вызывать эскалацию конфликта
- Не завистливые, которые в конкретной игре не пытаются «выиграть» соперника и набрать больше очков.
Ничего не пропагандирую, но можете об этом вспомнить, стоя перед выбором в следующий раз.
P.S. Кстати, об этом же пишет Наваль Равикант в «Как стать богатым»: играйте в долгосрочные игры с постоянными людьми. Долгосрочные игроки обогащают друг друга.
UPD: а в комментария подсказали ссылку на офигенную игру-визуализацию
Работая в команде часто приходится стоять перед выбором, как решить какую-то задачу. Пойти и быстро сделать самому, потому что так проще или научить кого-то, потратить больше сил и времени и уменьшить базфактор? Написать код, чтобы он просто работал или написать его так, чтобы его ещё можно было читать и поддерживать? Молча сделать, как сказали или разобраться в том, что на самом деле от нас хотели и предложить решение лучше?
Чаще всего мы выбираем между быстрой, большой личной выгодой (экономим силы/время) и долгосрочной небольшой выгодой для всех. Очень похоже на дилемму заключенного где сотрудничество – это решение в пользу команды, предательство – решение в личную пользу. За исключением того, что тут никто никого реально не предает (если, конечно, не забывает писать тесты и обновлять документацию). Напомню, суть дилеммы – это выбор сотрудничать или предавать в ситуации:
- Если Вася и Петя сотрудничают – они получают некоторую выгоду
- Если Вася предает Петю, а Петя сотрудничает с Васей, то Вася получает максимальную выгоду, а Петя ничего не получает. И наоборот
- Если они предают друг друга – оба получают наименьшую выгоду.
В 1984 году Роберт Аксельрод в книге «The Evolution of Cooperation» описал различные тактики принятия решения в повторяющейся дилемме заключенного (когда Вася помнит, как вел себя Петя до этого и принимает своё решение основываясь на этом). Это были изначально враждебные или дружелюбные алгоритмы; жадные или щедрые; мстительные и прощающие. В эксперименте стратегии сталкивали друг с другом и смотрели, какие стратегии зарабатывают больше очков. В итоге лидировали:
- Добрые, которые никогда не предают первыми
- Мстительные. Всегда сотрудничать это плохой выбор, т.к. рано или поздно попадётся «злая» стратегия, которая будет этим пользоваться. Но в то же время они должны быть прощающими, т.к. постоянная месть может вызывать эскалацию конфликта
- Не завистливые, которые в конкретной игре не пытаются «выиграть» соперника и набрать больше очков.
Ничего не пропагандирую, но можете об этом вспомнить, стоя перед выбором в следующий раз.
P.S. Кстати, об этом же пишет Наваль Равикант в «Как стать богатым»: играйте в долгосрочные игры с постоянными людьми. Долгосрочные игроки обогащают друг друга.
UPD: а в комментария подсказали ссылку на офигенную игру-визуализацию
Про постановку задач и законы UX
В проектировании интерфейсов иногда вспоминают про закон Фиттса, который говорит о том, что скорость перемещения курсора на объект на экране зависит от расстояния, которое нужно до объекта преодолеть и его размера. Простым языком: чем дальше вести курсор и чем дольше целиться – тем сложнее попасть. Причем эксперименты показывают, что зависимость логарифмическая, а это значит что до определённого момента даже небольшое увеличение размера объекта сильно влияет на скорость попадания по нему.
В применении этого закона появились и некоторые хаки. Например, в мобильных интерфейсах часто «кликабельная» зона кнопок больше, чем видимая. Или кнопка пуск в windows (кстати, она ещё существует?): вроде бы она всегда далеко, где-то в углу и размер её совсем не большой. Но из-за того, что экран ограничен простое движение куда-то вниз и влево точно приведёт к этой кнопке и можно не тратить время на прицеливание. Такая кнопка считается бесконечно большой.
Так вот, когда вы ставите задачи (как другим людям, так и себе) – вы в каком-то смысле занимаетесь проектированием «интерфейса этой задачи». А значит тут применимы те же правила:
- Чем сильнее контекст задачи отличается от текущего контекста того, кому вы её ставите, тем сложнее её выполнить (по аналогии с кнопками, далеко расположенными друг от друга). Имеет смысл группировать задачи по контексту (например, сначала делаем все задачи по проектирование архитектуры приложения, а потом переходим к HR)
- Чем больше описано контекста и деталей в задаче (аналогия – чем больше кнопка) – тем проще её выполнить. Опять же, даже если вы ставите задачу самому себе – намного проще взять и сделать ту, в которой нужно меньше разбираться.
- До некоторых пор даже малейшее добавление контекста сильно упрощает выполнение задачи, но переизбыток информации почти не влияет на результат.
В общем, не забывайте про интерфейс ваших задач. А если научитесь ставить «бесконечно большие» задачи – расскажите мне, как это делать.
В проектировании интерфейсов иногда вспоминают про закон Фиттса, который говорит о том, что скорость перемещения курсора на объект на экране зависит от расстояния, которое нужно до объекта преодолеть и его размера. Простым языком: чем дальше вести курсор и чем дольше целиться – тем сложнее попасть. Причем эксперименты показывают, что зависимость логарифмическая, а это значит что до определённого момента даже небольшое увеличение размера объекта сильно влияет на скорость попадания по нему.
В применении этого закона появились и некоторые хаки. Например, в мобильных интерфейсах часто «кликабельная» зона кнопок больше, чем видимая. Или кнопка пуск в windows (кстати, она ещё существует?): вроде бы она всегда далеко, где-то в углу и размер её совсем не большой. Но из-за того, что экран ограничен простое движение куда-то вниз и влево точно приведёт к этой кнопке и можно не тратить время на прицеливание. Такая кнопка считается бесконечно большой.
Так вот, когда вы ставите задачи (как другим людям, так и себе) – вы в каком-то смысле занимаетесь проектированием «интерфейса этой задачи». А значит тут применимы те же правила:
- Чем сильнее контекст задачи отличается от текущего контекста того, кому вы её ставите, тем сложнее её выполнить (по аналогии с кнопками, далеко расположенными друг от друга). Имеет смысл группировать задачи по контексту (например, сначала делаем все задачи по проектирование архитектуры приложения, а потом переходим к HR)
- Чем больше описано контекста и деталей в задаче (аналогия – чем больше кнопка) – тем проще её выполнить. Опять же, даже если вы ставите задачу самому себе – намного проще взять и сделать ту, в которой нужно меньше разбираться.
- До некоторых пор даже малейшее добавление контекста сильно упрощает выполнение задачи, но переизбыток информации почти не влияет на результат.
В общем, не забывайте про интерфейс ваших задач. А если научитесь ставить «бесконечно большие» задачи – расскажите мне, как это делать.
Про кроссфит и развитие продуктов
В какой-то момент после того, как я начал заниматься кроссфитом, я задумался – как оценивают участников соревнований? Ведь на самом деле, это не один вид спорта, а много. Кто лучше – тот, кто больше всех потянул в становой тяге 200кг или тот, кто быстрее всех прогреб 1.5км? В итоге система оказалась супер-простой: в каждом комплексе у участников проходит отдельный зачет, а итоговый результат – это сумма мест. То есть если ты первый в становой тяге, десятый в гребле и пятый в бёрпи – то в итоге у тебя 1+10+5 баллов. После чего делается общий рейтинг по всем комплексам.
Самое интересное тут то, что очень часто победители в общем зачете не входят в топы в отдельных комплексах (реальную картину можно найти в результатах crossfit games). То есть вероятность стать победителем намного выше, если ты достаточно хорош в нескольких дисциплинах, чем если ты топ-1 в одной.
Уверен, что таких же принципов стоит придерживаться и в развитии продуктов (в широком смысле этого слова – от развития себя до развития компаний). Скотт Адамс (автор книги «How to Fail at Almost Everything and Still Win Big» и комиксов, которые вы наверняка встречали в интернете) пишет у себя в блоге: чтобы достичь экстраординарных результатов у вас есть 2 пути: стать лучшим в чём-то одном или войти в топ 25% в двух или более вещах.
Допустим, у вас есть выбор человека в команду. Один – нереально крутой программист. Он знает свой язык программирования лучше, чем Матц знает руби, Линус Торвальдс линукс, а Сократ то, что он ничего не знает. Но вот беда: с ним невозможно разговаривать, он непонятно пишет сообщения в мессенджере, все задачи делает в 2 раза дольше, чем рассчитывает, а его код в итоге никто не понимает. А второй – достаточно хороший программист (хоть и не ответил на собеседовании, почему люки круглые), он достаточно хорошо объясняет свои мысли (хотя иногда его не понимают), пишет тексты (хотя ему точно не хватает Ильяхова), а ещё как-будто что-то знает о продажах, потому что продакты его слушают и включают технический долг в планы. Кого вы бы наняли?
Или с другой стороны: есть 2 компании. В одной самые высокие зарплаты на рынке, но в команде отношения напряженные, проект – легаси, нет целей, лидеров, аналитики (ладно хоть есть печеньки на кухне). А во второй зарплата на 15% ниже, но понятный проект (хотя вы о нём ничего не слышали до этого), процессы (но недостаточно скрама), адекватный руководитель (но ни на одной конфе не засветился и блог не ведёт), компенсируют конференции с английским на 70%. Кого бы вы выбрали?
В общем, все мы регулярно немного участвуем в соревнованиях по кроссфиту. И даже если не можем быть топ-1 в чем-то одном, в общем зачете всё ещё велики шансы. А различные сочетания делают людей и компании уникальными. Кто знает, может даже кроссфит, разработку, hr и написание текстов можно как-то связать.
В какой-то момент после того, как я начал заниматься кроссфитом, я задумался – как оценивают участников соревнований? Ведь на самом деле, это не один вид спорта, а много. Кто лучше – тот, кто больше всех потянул в становой тяге 200кг или тот, кто быстрее всех прогреб 1.5км? В итоге система оказалась супер-простой: в каждом комплексе у участников проходит отдельный зачет, а итоговый результат – это сумма мест. То есть если ты первый в становой тяге, десятый в гребле и пятый в бёрпи – то в итоге у тебя 1+10+5 баллов. После чего делается общий рейтинг по всем комплексам.
Самое интересное тут то, что очень часто победители в общем зачете не входят в топы в отдельных комплексах (реальную картину можно найти в результатах crossfit games). То есть вероятность стать победителем намного выше, если ты достаточно хорош в нескольких дисциплинах, чем если ты топ-1 в одной.
Уверен, что таких же принципов стоит придерживаться и в развитии продуктов (в широком смысле этого слова – от развития себя до развития компаний). Скотт Адамс (автор книги «How to Fail at Almost Everything and Still Win Big» и комиксов, которые вы наверняка встречали в интернете) пишет у себя в блоге: чтобы достичь экстраординарных результатов у вас есть 2 пути: стать лучшим в чём-то одном или войти в топ 25% в двух или более вещах.
Допустим, у вас есть выбор человека в команду. Один – нереально крутой программист. Он знает свой язык программирования лучше, чем Матц знает руби, Линус Торвальдс линукс, а Сократ то, что он ничего не знает. Но вот беда: с ним невозможно разговаривать, он непонятно пишет сообщения в мессенджере, все задачи делает в 2 раза дольше, чем рассчитывает, а его код в итоге никто не понимает. А второй – достаточно хороший программист (хоть и не ответил на собеседовании, почему люки круглые), он достаточно хорошо объясняет свои мысли (хотя иногда его не понимают), пишет тексты (хотя ему точно не хватает Ильяхова), а ещё как-будто что-то знает о продажах, потому что продакты его слушают и включают технический долг в планы. Кого вы бы наняли?
Или с другой стороны: есть 2 компании. В одной самые высокие зарплаты на рынке, но в команде отношения напряженные, проект – легаси, нет целей, лидеров, аналитики (ладно хоть есть печеньки на кухне). А во второй зарплата на 15% ниже, но понятный проект (хотя вы о нём ничего не слышали до этого), процессы (но недостаточно скрама), адекватный руководитель (но ни на одной конфе не засветился и блог не ведёт), компенсируют конференции с английским на 70%. Кого бы вы выбрали?
В общем, все мы регулярно немного участвуем в соревнованиях по кроссфиту. И даже если не можем быть топ-1 в чем-то одном, в общем зачете всё ещё велики шансы. А различные сочетания делают людей и компании уникальными. Кто знает, может даже кроссфит, разработку, hr и написание текстов можно как-то связать.
Про муравьёв и шаринг знаний
Задача коммивояжера – классическая математическая задача. Как оптимальным способом обойти несколько городов и вернуться обратно? Один из популярных алгоритмов решения – так называемый муравьиный алгоритм. Это отсылка к реальному поведению муравьев при поиске еды: они идут от гнезда в поисках еды в случайном направлении и если находят – то возвращаются назад, выделяя феромоны. Следующие муравьи уже с бóльшей вероятностью (но не в 100% случаев) выбирают путь с феромонами зная, что кто-то вернулся по этому пути с едой. Причем феромоны постепенно испаряются, из-за чего длинные пути «остывают» (ведь на поход от гнезда до еды и обратно уходит много времени), а короткие становятся всё более привлекательными.
Причем тут шаринг знаний? Кажется, тут всё работает аналогичным образом. На самом деле любая документация или рассказ о своём опыте – это «тропы» которые мы прокладываем для того, чтобы нашим последователям было проще. И прокладываем их мы только тогда, когда поняли – сработал этот путь или нет. И правила тут аналогичные:
– Лучше рассказывать даже про неоптимальные решения, чем не рассказывать совсем. Кому-то рано или поздно это облегчит жизнь и ему не придётся начинать поиски с нуля.
– Чем больше участников будут вкладываться в общее дело, тем оптимальнее будут решения. Привлекайте людей создавать общие системы, а не плодить свои.
– Если «ходить по тропе в одну сторону» и только использовать чужие знания, но не делиться своими, то тропа будет выветриваться (а документация будет становиться неактуальной). Поддерживайте актуальность знаний, которые вы используете.
- Самые «натоптанные» тропы, о которых говорят больше всего будут чаще всего использоваться.
В общем, если даже муравьи могут – значит мы можем лучше. Но помните, что не всегда решение, найденное муравьиным алгоритмом – оптимальное.
Задача коммивояжера – классическая математическая задача. Как оптимальным способом обойти несколько городов и вернуться обратно? Один из популярных алгоритмов решения – так называемый муравьиный алгоритм. Это отсылка к реальному поведению муравьев при поиске еды: они идут от гнезда в поисках еды в случайном направлении и если находят – то возвращаются назад, выделяя феромоны. Следующие муравьи уже с бóльшей вероятностью (но не в 100% случаев) выбирают путь с феромонами зная, что кто-то вернулся по этому пути с едой. Причем феромоны постепенно испаряются, из-за чего длинные пути «остывают» (ведь на поход от гнезда до еды и обратно уходит много времени), а короткие становятся всё более привлекательными.
Причем тут шаринг знаний? Кажется, тут всё работает аналогичным образом. На самом деле любая документация или рассказ о своём опыте – это «тропы» которые мы прокладываем для того, чтобы нашим последователям было проще. И прокладываем их мы только тогда, когда поняли – сработал этот путь или нет. И правила тут аналогичные:
– Лучше рассказывать даже про неоптимальные решения, чем не рассказывать совсем. Кому-то рано или поздно это облегчит жизнь и ему не придётся начинать поиски с нуля.
– Чем больше участников будут вкладываться в общее дело, тем оптимальнее будут решения. Привлекайте людей создавать общие системы, а не плодить свои.
– Если «ходить по тропе в одну сторону» и только использовать чужие знания, но не делиться своими, то тропа будет выветриваться (а документация будет становиться неактуальной). Поддерживайте актуальность знаний, которые вы используете.
- Самые «натоптанные» тропы, о которых говорят больше всего будут чаще всего использоваться.
В общем, если даже муравьи могут – значит мы можем лучше. Но помните, что не всегда решение, найденное муравьиным алгоритмом – оптимальное.
👍1