Про «синьорность»
– Привет! Нам нужно разместить 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 gives you a view of how a technology or application will evolve over time, providing a sound source of insight to manage its deployment within the context of your specific business goals.
💡 Про несостоятельные гипотезы
В продуктовой разработке сейчас все разговоры про гипотезы. Средний продакт или маркетолог по 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
Wikipedia
Знание задним числом
Зна́ние за́дним число́м (англ. hindsight bias) — когнитивное искажение, склонность воспринимать события, которые уже произошли, или факты, которые уже были установлены, как очевидные и предсказуемые, несмотря на отсутствие достаточной первоначальной информации…
Про 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: а в комментария подсказали ссылку на офигенную игру-визуализацию
Wikipedia
Дилемма заключённого
Базовый принцип из теории игр
Про постановку задач и законы UX
В проектировании интерфейсов иногда вспоминают про закон Фиттса, который говорит о том, что скорость перемещения курсора на объект на экране зависит от расстояния, которое нужно до объекта преодолеть и его размера. Простым языком: чем дальше вести курсор и чем дольше целиться – тем сложнее попасть. Причем эксперименты показывают, что зависимость логарифмическая, а это значит что до определённого момента даже небольшое увеличение размера объекта сильно влияет на скорость попадания по нему.
В применении этого закона появились и некоторые хаки. Например, в мобильных интерфейсах часто «кликабельная» зона кнопок больше, чем видимая. Или кнопка пуск в windows (кстати, она ещё существует?): вроде бы она всегда далеко, где-то в углу и размер её совсем не большой. Но из-за того, что экран ограничен простое движение куда-то вниз и влево точно приведёт к этой кнопке и можно не тратить время на прицеливание. Такая кнопка считается бесконечно большой.
Так вот, когда вы ставите задачи (как другим людям, так и себе) – вы в каком-то смысле занимаетесь проектированием «интерфейса этой задачи». А значит тут применимы те же правила:
- Чем сильнее контекст задачи отличается от текущего контекста того, кому вы её ставите, тем сложнее её выполнить (по аналогии с кнопками, далеко расположенными друг от друга). Имеет смысл группировать задачи по контексту (например, сначала делаем все задачи по проектирование архитектуры приложения, а потом переходим к HR)
- Чем больше описано контекста и деталей в задаче (аналогия – чем больше кнопка) – тем проще её выполнить. Опять же, даже если вы ставите задачу самому себе – намного проще взять и сделать ту, в которой нужно меньше разбираться.
- До некоторых пор даже малейшее добавление контекста сильно упрощает выполнение задачи, но переизбыток информации почти не влияет на результат.
В общем, не забывайте про интерфейс ваших задач. А если научитесь ставить «бесконечно большие» задачи – расскажите мне, как это делать.
В проектировании интерфейсов иногда вспоминают про закон Фиттса, который говорит о том, что скорость перемещения курсора на объект на экране зависит от расстояния, которое нужно до объекта преодолеть и его размера. Простым языком: чем дальше вести курсор и чем дольше целиться – тем сложнее попасть. Причем эксперименты показывают, что зависимость логарифмическая, а это значит что до определённого момента даже небольшое увеличение размера объекта сильно влияет на скорость попадания по нему.
В применении этого закона появились и некоторые хаки. Например, в мобильных интерфейсах часто «кликабельная» зона кнопок больше, чем видимая. Или кнопка пуск в windows (кстати, она ещё существует?): вроде бы она всегда далеко, где-то в углу и размер её совсем не большой. Но из-за того, что экран ограничен простое движение куда-то вниз и влево точно приведёт к этой кнопке и можно не тратить время на прицеливание. Такая кнопка считается бесконечно большой.
Так вот, когда вы ставите задачи (как другим людям, так и себе) – вы в каком-то смысле занимаетесь проектированием «интерфейса этой задачи». А значит тут применимы те же правила:
- Чем сильнее контекст задачи отличается от текущего контекста того, кому вы её ставите, тем сложнее её выполнить (по аналогии с кнопками, далеко расположенными друг от друга). Имеет смысл группировать задачи по контексту (например, сначала делаем все задачи по проектирование архитектуры приложения, а потом переходим к HR)
- Чем больше описано контекста и деталей в задаче (аналогия – чем больше кнопка) – тем проще её выполнить. Опять же, даже если вы ставите задачу самому себе – намного проще взять и сделать ту, в которой нужно меньше разбираться.
- До некоторых пор даже малейшее добавление контекста сильно упрощает выполнение задачи, но переизбыток информации почти не влияет на результат.
В общем, не забывайте про интерфейс ваших задач. А если научитесь ставить «бесконечно большие» задачи – расскажите мне, как это делать.
Wikipedia
Fitts's law
predictive model of human movement
Про кроссфит и развитие продуктов
В какой-то момент после того, как я начал заниматься кроссфитом, я задумался – как оценивают участников соревнований? Ведь на самом деле, это не один вид спорта, а много. Кто лучше – тот, кто больше всех потянул в становой тяге 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% случаев) выбирают путь с феромонами зная, что кто-то вернулся по этому пути с едой. Причем феромоны постепенно испаряются, из-за чего длинные пути «остывают» (ведь на поход от гнезда до еды и обратно уходит много времени), а короткие становятся всё более привлекательными.
Причем тут шаринг знаний? Кажется, тут всё работает аналогичным образом. На самом деле любая документация или рассказ о своём опыте – это «тропы» которые мы прокладываем для того, чтобы нашим последователям было проще. И прокладываем их мы только тогда, когда поняли – сработал этот путь или нет. И правила тут аналогичные:
– Лучше рассказывать даже про неоптимальные решения, чем не рассказывать совсем. Кому-то рано или поздно это облегчит жизнь и ему не придётся начинать поиски с нуля.
– Чем больше участников будут вкладываться в общее дело, тем оптимальнее будут решения. Привлекайте людей создавать общие системы, а не плодить свои.
– Если «ходить по тропе в одну сторону» и только использовать чужие знания, но не делиться своими, то тропа будет выветриваться (а документация будет становиться неактуальной). Поддерживайте актуальность знаний, которые вы используете.
- Самые «натоптанные» тропы, о которых говорят больше всего будут чаще всего использоваться.
В общем, если даже муравьи могут – значит мы можем лучше. Но помните, что не всегда решение, найденное муравьиным алгоритмом – оптимальное.
Time-to метрики
Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product-market fit. Но почему-то редко анализируются другие time-to метрики, а чем меньше нужно времени (и мозговых ресурсов) на какое-то действие, тем больше времени остаётся для других дел.
У вас наверняка случались ситуации, когда вы собирались сделать простейшую задачу, но из-за возникающих сложностей забивали. Например: пошли смотреть запись демо → оказались разлогинены → долго вспоминали пароль → оказалось, что у вас нет прав → попросили эти права вам дать → человек, который мог это сделать был на обеде → дал права через час, когда вернулся → вы уже заняты другими вещами. В итоге у вас стало меньше понимания, что нового было сделано в продукте и зачем.
Или шли налить себе кофе → кружка на другом этаже → вернулись, а в кофе машине кончилась вода → наполнили бак → ещё и кофе нужно насыпать → «ой, не больно то и хотелось». В результате вы ушли на очередную встречу раздражительнее, из-за чего она прошла менее конструктивно.
На какое ещё время можно обращать внимание?
– Time-to-data – время на доступ к информации. Как сложно найти нужную информацию? Например, почему сделали изменение в коде? Где взять логин и пароль в админку аналитического сервиса? Какие были договорённости на прошлом планировании? Где и как мы можем хранить эту информацию? Как сделать так, чтобы её можно было легко и быстро найти?
– Time-to-action – время для действия. Сколько времени нужно, чтобы начать что-то делать? Например, к вам на проект пришел новый разработчик – сколько проходит времени до его первого коммита? Как можно это ускорить? Завернуть всё в докер? Предоставить компьютер с предустановленным и настроенным проектом? Потратить час на поверхностное объяснение проекта или скинуть ссылку на подробнейшую документацию на 500 страниц?
– Time-to-decision – время для принятия решения. Сколько времени уходит на принятие решения в команде? Если вы каждый свой шаг согласовываете, то дела у вас наверняка идут очень медленно, а большой процент начатых активностей просто глохнет. Может можно что-то просто взять и сделать без апрува сверху или от всей команды? Или заранее всем вместе решить, кто какие решения принимает и в каких вопросах хочет принимать участие, например с помощью delegation poker?
– Time-to-interaction – время на взаимодействие с другими людьми. Сколько времени ждать code-review? А сколько времени уйдёт у другого разработчика на этот code-review? На что из этого вы можете повлиять? Как это время уменьшить?
– Time-to-small-things - время на разные мелочи. Наверняка, в день вы делаете сотни и тысячи мелких действий и небольшое ускорение в них может освободить вам голову и время. Как быстро вы печатаете? Как быстро навигируетесь в проекте/коде? Используете шорткаты? А time-to-coffee у вас какой?
В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?
Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product-market fit. Но почему-то редко анализируются другие time-to метрики, а чем меньше нужно времени (и мозговых ресурсов) на какое-то действие, тем больше времени остаётся для других дел.
У вас наверняка случались ситуации, когда вы собирались сделать простейшую задачу, но из-за возникающих сложностей забивали. Например: пошли смотреть запись демо → оказались разлогинены → долго вспоминали пароль → оказалось, что у вас нет прав → попросили эти права вам дать → человек, который мог это сделать был на обеде → дал права через час, когда вернулся → вы уже заняты другими вещами. В итоге у вас стало меньше понимания, что нового было сделано в продукте и зачем.
Или шли налить себе кофе → кружка на другом этаже → вернулись, а в кофе машине кончилась вода → наполнили бак → ещё и кофе нужно насыпать → «ой, не больно то и хотелось». В результате вы ушли на очередную встречу раздражительнее, из-за чего она прошла менее конструктивно.
На какое ещё время можно обращать внимание?
– Time-to-data – время на доступ к информации. Как сложно найти нужную информацию? Например, почему сделали изменение в коде? Где взять логин и пароль в админку аналитического сервиса? Какие были договорённости на прошлом планировании? Где и как мы можем хранить эту информацию? Как сделать так, чтобы её можно было легко и быстро найти?
– Time-to-action – время для действия. Сколько времени нужно, чтобы начать что-то делать? Например, к вам на проект пришел новый разработчик – сколько проходит времени до его первого коммита? Как можно это ускорить? Завернуть всё в докер? Предоставить компьютер с предустановленным и настроенным проектом? Потратить час на поверхностное объяснение проекта или скинуть ссылку на подробнейшую документацию на 500 страниц?
– Time-to-decision – время для принятия решения. Сколько времени уходит на принятие решения в команде? Если вы каждый свой шаг согласовываете, то дела у вас наверняка идут очень медленно, а большой процент начатых активностей просто глохнет. Может можно что-то просто взять и сделать без апрува сверху или от всей команды? Или заранее всем вместе решить, кто какие решения принимает и в каких вопросах хочет принимать участие, например с помощью delegation poker?
– Time-to-interaction – время на взаимодействие с другими людьми. Сколько времени ждать code-review? А сколько времени уйдёт у другого разработчика на этот code-review? На что из этого вы можете повлиять? Как это время уменьшить?
– Time-to-small-things - время на разные мелочи. Наверняка, в день вы делаете сотни и тысячи мелких действий и небольшое ускорение в них может освободить вам голову и время. Как быстро вы печатаете? Как быстро навигируетесь в проекте/коде? Используете шорткаты? А time-to-coffee у вас какой?
В общем, иногда достаточно просто начать обращать внимание на то, куда уходит время – идеи о том, как ускориться придут сами. Так же полезно думать об этом, когда вы создаёте продукты и процессы для других – как вы можете ускорить и упростить для них использование вашего процесса/продукта?
Management 3.0
Delegation Poker: A Management 3.0 Game
Use Delegation Poker to clarify who’s responsible for what and to what level. This is a method where you can encourage employee engagement through controlled self-organization and clarified value and decision-making.
Найм 2.0
Пару недель назад вышла очередная HR-аналитика от NewHR. Как мне кажется, там много чего драматизировано и преувеличено (если рассматривать это как исследование рынка РФ в целом), но там есть фраза, точно описывающая текущую ситуацию: «рынок найма превратился в рынок кандидата».
И это, конечно, нужно учитывать и адаптировать процесс найма под кандидатов. Вот что, например, можно попробовать:
– Подчеркивать свои отличия от остальных. Уже у всех есть удалёнка, свободный график и «дружный коллектив». А что отличает именно вашу компанию? Четкие регламенты и систематизация всего или наоборот, высокая гибкость и уровень свободы? Наличие харизматичных лидеров или возможность им стать?
– Адаптироваться под кандидата. Если ему удобнее созваниваться после рабочего дня – придётся найти время. Если не удобно с камерой – можно и без неё (вы же человека на удалёнку собеседуете?). Если человек заикается – можно перевести собеседование в текстовый, более удобный для него формат (заодно и сами такой формат потестируете).
– Не пытаться нанять любого, только ради закрытия вакансии. Вообще на рынке действует правило «любой сотрудник может получить оффер лучше текущего, а любой работодатель может найти сотрудника, который тот же объем работы будет делать за меньшие деньги. Вопрос только в методах поиска и времени». Так что рано или поздно вы найдете своего кандидата (ну только если ваша компания доживет до этого момента).
– Сделать собеседования полезными для кандидата, а не только для вас. Помните, что собеседование – двусторонний процесс. Давайте подробный фидбек, делитесь своим опытом, рекомендуйте книги/курсы/лекции – пусть кандидат уйдет от вас лучше, чем пришел, даже если уйдет без оффера.
В общем, хотите чтобы люди стремились у вас работать? Покажите настоящих себя и сделайте ваши собеседования полезными для кандидатов.
Пару недель назад вышла очередная HR-аналитика от NewHR. Как мне кажется, там много чего драматизировано и преувеличено (если рассматривать это как исследование рынка РФ в целом), но там есть фраза, точно описывающая текущую ситуацию: «рынок найма превратился в рынок кандидата».
И это, конечно, нужно учитывать и адаптировать процесс найма под кандидатов. Вот что, например, можно попробовать:
– Подчеркивать свои отличия от остальных. Уже у всех есть удалёнка, свободный график и «дружный коллектив». А что отличает именно вашу компанию? Четкие регламенты и систематизация всего или наоборот, высокая гибкость и уровень свободы? Наличие харизматичных лидеров или возможность им стать?
– Адаптироваться под кандидата. Если ему удобнее созваниваться после рабочего дня – придётся найти время. Если не удобно с камерой – можно и без неё (вы же человека на удалёнку собеседуете?). Если человек заикается – можно перевести собеседование в текстовый, более удобный для него формат (заодно и сами такой формат потестируете).
– Не пытаться нанять любого, только ради закрытия вакансии. Вообще на рынке действует правило «любой сотрудник может получить оффер лучше текущего, а любой работодатель может найти сотрудника, который тот же объем работы будет делать за меньшие деньги. Вопрос только в методах поиска и времени». Так что рано или поздно вы найдете своего кандидата (ну только если ваша компания доживет до этого момента).
– Сделать собеседования полезными для кандидата, а не только для вас. Помните, что собеседование – двусторонний процесс. Давайте подробный фидбек, делитесь своим опытом, рекомендуйте книги/курсы/лекции – пусть кандидат уйдет от вас лучше, чем пришел, даже если уйдет без оффера.
В общем, хотите чтобы люди стремились у вас работать? Покажите настоящих себя и сделайте ваши собеседования полезными для кандидатов.
Про подмену понятий
Человек по своей природе очень ленивый. Все точно слышали, что лень – двигатель прогресса, но почему-то людям очень стыдно признаваться в своей лени (хотя прогресс вокруг показывает, что это очень даже позитивное явление). Но как на нас будут смотреть люди, если мы им прямо скажем, что нам что-то лень? Такой ход мыслей приводит к тому, что мы ищем более социально-значимые оправдания и регулярно подменяем понятия. Например:
– «Я не смогу этим заняться – у меня нет времени». Почти любая книжка по тайм-менеджменту начинается с того, что напоминает, что у всех в сутках 24 часа. Так вот часто, когда мы говорим, что у нас нет времени, то на самом деле у нас нет желания/мотивации/энергии («мыслетоплива», в терминах «Джедайских техник» Дорофеева)
– «Давайте не будем это пробовать – это не удобно». Моё любимое – всем лень разбираться в чём-то новом. Конечно, чтобы новый инструмент начал приносить пользу – в нём нужно разобраться и потратить на это время, а пока этого не сделаешь – этот инструмент будет непривычным. Но главное помнить: непривычно – не значит неудобно.
– «Давайте не будем это делать – это слишком сложно!». Конечно, намного проще найти самое сложное решение задачи и оправдаться этой самой сложностью, чем потратить время, найти баланс между ленью и сложностью решения и что-то сделать (а искать простые решения – сложно).
В общем, если не хотите чем-то заниматься - подумайте, из-за чего на самом деле? И не стесняйтесь признаваться себе в лени – возможно именно она поможет.
Человек по своей природе очень ленивый. Все точно слышали, что лень – двигатель прогресса, но почему-то людям очень стыдно признаваться в своей лени (хотя прогресс вокруг показывает, что это очень даже позитивное явление). Но как на нас будут смотреть люди, если мы им прямо скажем, что нам что-то лень? Такой ход мыслей приводит к тому, что мы ищем более социально-значимые оправдания и регулярно подменяем понятия. Например:
– «Я не смогу этим заняться – у меня нет времени». Почти любая книжка по тайм-менеджменту начинается с того, что напоминает, что у всех в сутках 24 часа. Так вот часто, когда мы говорим, что у нас нет времени, то на самом деле у нас нет желания/мотивации/энергии («мыслетоплива», в терминах «Джедайских техник» Дорофеева)
– «Давайте не будем это пробовать – это не удобно». Моё любимое – всем лень разбираться в чём-то новом. Конечно, чтобы новый инструмент начал приносить пользу – в нём нужно разобраться и потратить на это время, а пока этого не сделаешь – этот инструмент будет непривычным. Но главное помнить: непривычно – не значит неудобно.
– «Давайте не будем это делать – это слишком сложно!». Конечно, намного проще найти самое сложное решение задачи и оправдаться этой самой сложностью, чем потратить время, найти баланс между ленью и сложностью решения и что-то сделать (а искать простые решения – сложно).
В общем, если не хотите чем-то заниматься - подумайте, из-за чего на самом деле? И не стесняйтесь признаваться себе в лени – возможно именно она поможет.