Про постановку задач и законы 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
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 часа. Так вот часто, когда мы говорим, что у нас нет времени, то на самом деле у нас нет желания/мотивации/энергии («мыслетоплива», в терминах «Джедайских техник» Дорофеева)
– «Давайте не будем это пробовать – это не удобно». Моё любимое – всем лень разбираться в чём-то новом. Конечно, чтобы новый инструмент начал приносить пользу – в нём нужно разобраться и потратить на это время, а пока этого не сделаешь – этот инструмент будет непривычным. Но главное помнить: непривычно – не значит неудобно.
– «Давайте не будем это делать – это слишком сложно!». Конечно, намного проще найти самое сложное решение задачи и оправдаться этой самой сложностью, чем потратить время, найти баланс между ленью и сложностью решения и что-то сделать (а искать простые решения – сложно).
В общем, если не хотите чем-то заниматься - подумайте, из-за чего на самом деле? И не стесняйтесь признаваться себе в лени – возможно именно она поможет.
Про башню из слоновой кости и окно в реальность
Ничто не показывает наши ошибки и неверно принятые решения лучше, чем реальность. Но кто любит замечать свои ошибки? Ведь намного комфортнее априори считать все решения правильными. Один из способов – ограничивать себя безопасным «пузырём», в котором нет места негативному фидбеку о нашей работе. Но рано или поздно этот пузырь лопается и информация извне сильно демотивирует. Выход – сразу сделать реальный фидбек контролируемым.
Например, разработчикам и дизайнерам полезно видеть, как их решения используются в реальности – для этого им нужно принимать участие в саппорте, заглядывать в аналитику, смотреть за реальным поведением пользователей. Информация об ошибке в коде, упавшая в мессенжер воспринимается намного спокойнее и ей придаётся намного меньше значения, чем сообщение от реального клиента, который требует возврат денег из-за неработающей кнопки. Или который потерял деньги из-за непонятного интерфейса. И вообще, увидеть своими глазами, как реальные люди не понимают, куда нажимать в вашем инновационном интерфейсе – бесценная пощечина, приводящая в чувства.
Разработчики, работающие с реальным миром, а не только с абстракциями в коде никогда не ответят вам «у меня всё работает» в ответ на баг, ведь для них как раз важно, чтобы работало не у них. Ещё неплохо может работать использование своего же продукта. Так, например, продуктовые дизайнеры в сервисах доставки могут пойти доставлять еду, ведь одно дело – придумывать интерфейсы сидя в комфортном офисе, а другое – брать заказ на доставку где-то в пробке на велосипеде под дождём (это реальный пример).
Для менеджеров даже существует специальный термин – ivory tower syndrome, синдром «башни из слоновой кости». Такие менеджеры отдаляются от команды/подчинённых, и принимают решения основываясь только на своей картине мира, но не понимают, как всё работает в реальности, почему и с какими трудностями сталкиваются люди. Таким менеджерам нужно чаще «выходить в поля», собирать фидбек и получать информацию о том, как же работает реальность.
В общем, если вдруг вокруг появляется башня из слоновой кости – пробивайте для себя окно в реальность, через которое вы будете узнавать, как на самом деле работают ваши решения, а не как вы себе это представляли.
Ничто не показывает наши ошибки и неверно принятые решения лучше, чем реальность. Но кто любит замечать свои ошибки? Ведь намного комфортнее априори считать все решения правильными. Один из способов – ограничивать себя безопасным «пузырём», в котором нет места негативному фидбеку о нашей работе. Но рано или поздно этот пузырь лопается и информация извне сильно демотивирует. Выход – сразу сделать реальный фидбек контролируемым.
Например, разработчикам и дизайнерам полезно видеть, как их решения используются в реальности – для этого им нужно принимать участие в саппорте, заглядывать в аналитику, смотреть за реальным поведением пользователей. Информация об ошибке в коде, упавшая в мессенжер воспринимается намного спокойнее и ей придаётся намного меньше значения, чем сообщение от реального клиента, который требует возврат денег из-за неработающей кнопки. Или который потерял деньги из-за непонятного интерфейса. И вообще, увидеть своими глазами, как реальные люди не понимают, куда нажимать в вашем инновационном интерфейсе – бесценная пощечина, приводящая в чувства.
Разработчики, работающие с реальным миром, а не только с абстракциями в коде никогда не ответят вам «у меня всё работает» в ответ на баг, ведь для них как раз важно, чтобы работало не у них. Ещё неплохо может работать использование своего же продукта. Так, например, продуктовые дизайнеры в сервисах доставки могут пойти доставлять еду, ведь одно дело – придумывать интерфейсы сидя в комфортном офисе, а другое – брать заказ на доставку где-то в пробке на велосипеде под дождём (это реальный пример).
Для менеджеров даже существует специальный термин – ivory tower syndrome, синдром «башни из слоновой кости». Такие менеджеры отдаляются от команды/подчинённых, и принимают решения основываясь только на своей картине мира, но не понимают, как всё работает в реальности, почему и с какими трудностями сталкиваются люди. Таким менеджерам нужно чаще «выходить в поля», собирать фидбек и получать информацию о том, как же работает реальность.
В общем, если вдруг вокруг появляется башня из слоновой кости – пробивайте для себя окно в реальность, через которое вы будете узнавать, как на самом деле работают ваши решения, а не как вы себе это представляли.
👍1
Про неопределённость
Многие ошибочно считают, что senior-специалистов отличает то, что они всегда уверены в том, что и как нужно делать. Что senior-специалисты строят абсолютно понятные и предсказуемые системы и процессы, но в быстро развивающихся продуктах и командах это невозможно. Никто в команде не может точно сказать, что нужно делать, как и какие потребуются ресурсы и сколько времени это займёт, можно лишь догадываться. На самом деле senior-специалисты принимают во внимание неопредлённость и свои незнания (и неопределённость и незнания людей вокруг) и строят системы и процессы с их учетом. Они понимают, что их оценки могут быть неверны, что код может сломаться, а люди их могут их понять неправильно.
Например, опытные product-менеджеры не просто приоритезируют новые фичи и гипотезы по их важности/деньгам/тону, с которым гипотеза была озвучена начальством. Они учитывают свою же уверенность в этих оценках (см. confidence в RICE).
Опытные разработчики чаще стараются удалять код, чем писать, чтобы уменьшать сложность систем и увеличивать их предсказуемость, а когда добавляют что-то новое – со всех сторон обкладываются мониторингами и алертами, ведь за свои 5/10/15 лет в разработке они поняли, что даже идеально написанный и протестированный код может сломаться у клиента и часто даже не по их вине.
Неопытный проджект-менеджер закидывает разработчикам новую фичу на оценку и ожидает точного срока, при несоблюдении которого будет приходить и спрашивать, а почему не уложились в свою же оценку? Опытный же понимает, что разработчики сами могут не знать, сколько может занять эта новая фича и узнает не срок, когда фича будет на продакшене, а срок, когда у разработчика будет достаточно данных, чтобы дать более-менее правильную оценку (а ещё лучше – работает без оценок). Кстати, некоторые системы ведения проектов построены вокруг идеи того, что на первой стадии работы над проектом мы не делаем ничего «осязаемого», мы просто уменьшаем количество unknowns о проекте, а во второй уже что-то делаем (см. hill charts в Basecamp).
В общем, не ожидайте, что всё, что вы делаете – правильно. Лучше заранее подумайте, как вы сможете как можно раньше понять, что сделали что-то неправильно?
Многие ошибочно считают, что senior-специалистов отличает то, что они всегда уверены в том, что и как нужно делать. Что senior-специалисты строят абсолютно понятные и предсказуемые системы и процессы, но в быстро развивающихся продуктах и командах это невозможно. Никто в команде не может точно сказать, что нужно делать, как и какие потребуются ресурсы и сколько времени это займёт, можно лишь догадываться. На самом деле senior-специалисты принимают во внимание неопредлённость и свои незнания (и неопределённость и незнания людей вокруг) и строят системы и процессы с их учетом. Они понимают, что их оценки могут быть неверны, что код может сломаться, а люди их могут их понять неправильно.
Например, опытные product-менеджеры не просто приоритезируют новые фичи и гипотезы по их важности/деньгам/тону, с которым гипотеза была озвучена начальством. Они учитывают свою же уверенность в этих оценках (см. confidence в RICE).
Опытные разработчики чаще стараются удалять код, чем писать, чтобы уменьшать сложность систем и увеличивать их предсказуемость, а когда добавляют что-то новое – со всех сторон обкладываются мониторингами и алертами, ведь за свои 5/10/15 лет в разработке они поняли, что даже идеально написанный и протестированный код может сломаться у клиента и часто даже не по их вине.
Неопытный проджект-менеджер закидывает разработчикам новую фичу на оценку и ожидает точного срока, при несоблюдении которого будет приходить и спрашивать, а почему не уложились в свою же оценку? Опытный же понимает, что разработчики сами могут не знать, сколько может занять эта новая фича и узнает не срок, когда фича будет на продакшене, а срок, когда у разработчика будет достаточно данных, чтобы дать более-менее правильную оценку (а ещё лучше – работает без оценок). Кстати, некоторые системы ведения проектов построены вокруг идеи того, что на первой стадии работы над проектом мы не делаем ничего «осязаемого», мы просто уменьшаем количество unknowns о проекте, а во второй уже что-то делаем (см. hill charts в Basecamp).
В общем, не ожидайте, что всё, что вы делаете – правильно. Лучше заранее подумайте, как вы сможете как можно раньше понять, что сделали что-то неправильно?
👍1
Эволюция мотивации менеджера
Работа менеджера и мотивация часто встречаются в одном предложении. Но в 90% случаев это предложение о том, что менеджеры должны мотивировать свою команду. Но как им мотивировать себя?
Когда я был разработчиком, меня всегда заряжали оживающие системы. Я мог уйти в состояние потока, нацепить наушники, включить звук на всю и за день или ночь закончить большой проект. В итоге я понимал – it's alive! Что-то можно увидеть, потрогать руками, оценить. Ложился спать с чувством выполненного долга, а утром уже искал новую задачу, чтобы снова это испытать. И так по кругу.
Потом моя роль сместилась в сторону «играющего тренера». Моя мотивация не изменилась – я продолжал кайфовать от оживающих систем, сделанных моими руками. Но моё время начала отбирать «ненастоящая работа» – встречи, планирования, собеседования, 1:1. Всё то, в результате чего я не создавал чего-то нового. Осязаемых результатов становилось всё меньше. Ненастоящей работы всё больше и из-за этого падала мотивация – постоянно хотелось отложить менеджерство и пойти что-то сделать руками.
Думаю, с такой ситуацией сталкиваются многие, переходящие из разработки или дизайна в менеджмент.
Как менять мышление?
Во-первых, нужно совершить переход от идеи «кайф, когда я сделал X» к «кайф, когда я помог людям сделать X». Задача менеджера тут – помогать команде со всех сторон. Нужна реорганизация процессов? Кажется, что люди не понимают друг друга? Нужно больше людей? Можно брать и заниматься этим, чтобы привести команду к желаемому результату.
Если провести аналогию между командой и двигателем, то задача менеджера – собрать все необходимые детали, поставить их в правильные места, отладить связь друг с другом. И начать регулярно менять масло. Самое сложное тут – не делать всё самому, а помогать делать другим.
В таком случае можно считать себя причастным к чужому результату. И да, в конечном итоге нужно начать немного паразитировать и научиться получать свой дофамин за счёт чужой работы.
Во-вторых, у менеджеров этого самого дофамина может быть больше, ведь команда (или команды) могут производить результатов намного больше и намного быстрее, чем одни руки. Главное – учиться замечать чужие результаты (а иногда это сложно, ведь многие просто не любят хвалиться своей работой). Также полезно, об этих результатах рассказывать всем вокруг.
В-третьих, можно заметить, что кроме результатов, которые можно потрогать и увидеть у менеджеров появляются новые, более эфемерные. Например, развитие сотрудников. Когда ты помогаешь информацией, фидбеком и подбором задач под нужды людей ты видишь, как быстро они растут.
Главное правило в поиске мотивации для менеджера – любой быстрый дофамин, большинство срочных маленьких дел отдаляют вас (и вашу команду) от больших результатов. Чем больше людей с вами работают, тем более отдалёнными будут результаты вашей работы и тем более не срочные и сложные задачи нужно выбирать.
В общем, занимайтесь тем, от чего вы кайфуете – люди намного продуктивнее, когда делают то, что им хочется, а не то, что нужно. Но идеально, когда это одно и тоже.
---
Поразмышлять о том, как менеджерам мотивировать себя мы договорились с Александром Кузовлевым, автором канала На шаг впереди, у которого в этом большой опыт – он руководил в качестве PM и CTO в нескольких стартапах. Его пост на эту тему читайте тут:
👉Как менеджеру мотивировать себя, если не видно прямого результата его работы?👈
Работа менеджера и мотивация часто встречаются в одном предложении. Но в 90% случаев это предложение о том, что менеджеры должны мотивировать свою команду. Но как им мотивировать себя?
Когда я был разработчиком, меня всегда заряжали оживающие системы. Я мог уйти в состояние потока, нацепить наушники, включить звук на всю и за день или ночь закончить большой проект. В итоге я понимал – it's alive! Что-то можно увидеть, потрогать руками, оценить. Ложился спать с чувством выполненного долга, а утром уже искал новую задачу, чтобы снова это испытать. И так по кругу.
Потом моя роль сместилась в сторону «играющего тренера». Моя мотивация не изменилась – я продолжал кайфовать от оживающих систем, сделанных моими руками. Но моё время начала отбирать «ненастоящая работа» – встречи, планирования, собеседования, 1:1. Всё то, в результате чего я не создавал чего-то нового. Осязаемых результатов становилось всё меньше. Ненастоящей работы всё больше и из-за этого падала мотивация – постоянно хотелось отложить менеджерство и пойти что-то сделать руками.
Думаю, с такой ситуацией сталкиваются многие, переходящие из разработки или дизайна в менеджмент.
Как менять мышление?
Во-первых, нужно совершить переход от идеи «кайф, когда я сделал X» к «кайф, когда я помог людям сделать X». Задача менеджера тут – помогать команде со всех сторон. Нужна реорганизация процессов? Кажется, что люди не понимают друг друга? Нужно больше людей? Можно брать и заниматься этим, чтобы привести команду к желаемому результату.
Если провести аналогию между командой и двигателем, то задача менеджера – собрать все необходимые детали, поставить их в правильные места, отладить связь друг с другом. И начать регулярно менять масло. Самое сложное тут – не делать всё самому, а помогать делать другим.
В таком случае можно считать себя причастным к чужому результату. И да, в конечном итоге нужно начать немного паразитировать и научиться получать свой дофамин за счёт чужой работы.
Во-вторых, у менеджеров этого самого дофамина может быть больше, ведь команда (или команды) могут производить результатов намного больше и намного быстрее, чем одни руки. Главное – учиться замечать чужие результаты (а иногда это сложно, ведь многие просто не любят хвалиться своей работой). Также полезно, об этих результатах рассказывать всем вокруг.
В-третьих, можно заметить, что кроме результатов, которые можно потрогать и увидеть у менеджеров появляются новые, более эфемерные. Например, развитие сотрудников. Когда ты помогаешь информацией, фидбеком и подбором задач под нужды людей ты видишь, как быстро они растут.
Главное правило в поиске мотивации для менеджера – любой быстрый дофамин, большинство срочных маленьких дел отдаляют вас (и вашу команду) от больших результатов. Чем больше людей с вами работают, тем более отдалёнными будут результаты вашей работы и тем более не срочные и сложные задачи нужно выбирать.
В общем, занимайтесь тем, от чего вы кайфуете – люди намного продуктивнее, когда делают то, что им хочется, а не то, что нужно. Но идеально, когда это одно и тоже.
---
Поразмышлять о том, как менеджерам мотивировать себя мы договорились с Александром Кузовлевым, автором канала На шаг впереди, у которого в этом большой опыт – он руководил в качестве PM и CTO в нескольких стартапах. Его пост на эту тему читайте тут:
👉Как менеджеру мотивировать себя, если не видно прямого результата его работы?👈
🔥1
Про конференции
За время ограничений и локдаунов я успел побывать в роли участника на нескольких онлайн конференциях. В итоге я понял, что если для образовательных целей такой формат и подходит, то неформальное общение и нетворкинг в кулуарах сложно организовать по зуму, в отличии от оффлайна. Хорошо, что оффлайн конференции ожили. Например, во второй половине марта пройдёт TeamLead Conf в Москве – го общаться.
А если вы менеджер или тим-лид, то вам наверняка есть, что рассказать о вашей работе. Для вас у меня есть 2 новости:
– Уже подано более 70 заявок на доклады, митапы и круглые столы, они продолжают поступать, но вы ещё успеваете подать заявку на доклад. Торопитесь присоединиться к самой масштабной тусовке тимлидов.
– Программный комитет готов помогать определиться с темой доклада или мастер-класса, помочь подготовить сам доклад или презентацию. Так что, если вы точно знаете, что хотите поделиться чем-то очень нужным и важным, но не знаете, с какой стороны подойти - пишите смело им, они помогут.
Формально всё описано здесь https://tlconf.info. Или пишите в личку руководителю программного комитета @dumtest.
За время ограничений и локдаунов я успел побывать в роли участника на нескольких онлайн конференциях. В итоге я понял, что если для образовательных целей такой формат и подходит, то неформальное общение и нетворкинг в кулуарах сложно организовать по зуму, в отличии от оффлайна. Хорошо, что оффлайн конференции ожили. Например, во второй половине марта пройдёт TeamLead Conf в Москве – го общаться.
А если вы менеджер или тим-лид, то вам наверняка есть, что рассказать о вашей работе. Для вас у меня есть 2 новости:
– Уже подано более 70 заявок на доклады, митапы и круглые столы, они продолжают поступать, но вы ещё успеваете подать заявку на доклад. Торопитесь присоединиться к самой масштабной тусовке тимлидов.
– Программный комитет готов помогать определиться с темой доклада или мастер-класса, помочь подготовить сам доклад или презентацию. Так что, если вы точно знаете, что хотите поделиться чем-то очень нужным и важным, но не знаете, с какой стороны подойти - пишите смело им, они помогут.
Формально всё описано здесь https://tlconf.info. Или пишите в личку руководителю программного комитета @dumtest.
👍1
Что развивать лидеру?
Частый кейс в IT, когда в команде «самый умный» становится руководителем. Например, программист тим-лидом, дизайнер – арт-директором. Но часто такие тим-лиды и арт-директора (как и те, кто их назначает) забывают, что при переходе в менеджмент даже самый rock-star-senior-ниндзя-staff-специалист становится junior-менеджером. И после перехода нужно развивать не столько hard-скилы в своём деле, сколько (как бы банально это не звучало) – лидерские качества.
Так что это за качества такие? Мне больше всего нравится типология, в которой все навыки можно разделить на 3 группы:
1. Интеллектуальное лидерство
Эта группа навыков развита у «самых умных» – им верят, потому что они крутые специалисты. Но нужно смириться, что перейдя в менеджмент нельзя всегда оставаться лучшим. Те, кто регулярно делают вещи своими руками, следят за индустрией и прокачивают hard-скилы быстро вас обгонят. Вам же нужно научиться доверять и делегировать, а самому прокачивать другие 2 типа лидерства, а интеллект проявлять в общих подходах к решению проблем, понимании соседних областей и общей картины, принятии стратегических решений.
2. Организационное лидерство
Проявляется в том, что менеджер может собрать людей и построить процессы так, что команда начинает функционировать, как хорошо отлаженная система (а желательно ещё и так, чтобы эти процессы никого не бесили). Он решает в команде проблемы коммуникаций, шаринга знаний, уменьшает bus-фактор, заранее понимает, где образуются бутылочные горлышки и решает эти проблемы, чтобы команда могла сфокусировано достигать своих целей.
3. Эмоциональное лидерство
Проявляется в том, что менеджер понимает мотивацию разных участников команды, умеет искать подход к разным людям, замечает упадок сил и признаки выгорания у членов команды и может заранее переключить на другие задачи или напомнить про отпуск. Умеет объяснить людям, в чём польза от их работы и на какие большие цели и задачи влияет их труд, управляет уровнем энергии и эмоциональным фоном в команде, разруливает конфликты (как внутренние, так и межкомандные).
Рекомендация сегодня одна: отличный TedTalk на тему эмоционального лидерства: Simon Sinek: How great leaders inspire action.
Частый кейс в IT, когда в команде «самый умный» становится руководителем. Например, программист тим-лидом, дизайнер – арт-директором. Но часто такие тим-лиды и арт-директора (как и те, кто их назначает) забывают, что при переходе в менеджмент даже самый rock-star-senior-ниндзя-staff-специалист становится junior-менеджером. И после перехода нужно развивать не столько hard-скилы в своём деле, сколько (как бы банально это не звучало) – лидерские качества.
Так что это за качества такие? Мне больше всего нравится типология, в которой все навыки можно разделить на 3 группы:
1. Интеллектуальное лидерство
Эта группа навыков развита у «самых умных» – им верят, потому что они крутые специалисты. Но нужно смириться, что перейдя в менеджмент нельзя всегда оставаться лучшим. Те, кто регулярно делают вещи своими руками, следят за индустрией и прокачивают hard-скилы быстро вас обгонят. Вам же нужно научиться доверять и делегировать, а самому прокачивать другие 2 типа лидерства, а интеллект проявлять в общих подходах к решению проблем, понимании соседних областей и общей картины, принятии стратегических решений.
2. Организационное лидерство
Проявляется в том, что менеджер может собрать людей и построить процессы так, что команда начинает функционировать, как хорошо отлаженная система (а желательно ещё и так, чтобы эти процессы никого не бесили). Он решает в команде проблемы коммуникаций, шаринга знаний, уменьшает bus-фактор, заранее понимает, где образуются бутылочные горлышки и решает эти проблемы, чтобы команда могла сфокусировано достигать своих целей.
3. Эмоциональное лидерство
Проявляется в том, что менеджер понимает мотивацию разных участников команды, умеет искать подход к разным людям, замечает упадок сил и признаки выгорания у членов команды и может заранее переключить на другие задачи или напомнить про отпуск. Умеет объяснить людям, в чём польза от их работы и на какие большие цели и задачи влияет их труд, управляет уровнем энергии и эмоциональным фоном в команде, разруливает конфликты (как внутренние, так и межкомандные).
Рекомендация сегодня одна: отличный TedTalk на тему эмоционального лидерства: Simon Sinek: How great leaders inspire action.
Всё сделали не так
Признавайтесь, сколько раз вы понимали, что вокруг вас всё сделано неправильно, а вы то точно знали, как нужно было делать? Процессы не те и вот если бы вы участвовали в их формировании – точно всё работало бы лучше. Код – ужасное легаси и вообще надо было другие технологии использовать. Работать вам приходится с некомпетентными людьми, но вот если бы вы занимались наймом – наняли бы правильных.
Проблема в том, что ретроспективно судить конечно проще (снова привет, когнитивные искажения). Ведь так не видно, как конечный продукт (команда, код, процесс) оказался в этой точке, какие решения и кем были приняты, какие были условия и ограничения. Но важнее другое: ценность людей для бизнеса не в знании, «как нужно было сделать», а в действиях здесь и сейчас.
Конечно, разработчику удобнее работать в неспешном темпе, когда есть время спроектировать сложную систему и всегда есть время на технический долг. Но ценным его делает умение понять требования бизнеса и в нужной ситуации наговнокодить, а в другой заложить время на проектирование и реализацию гибкой и стабильной системы. Так же как и умение не только писать проект хорошо с нуля, но и поддерживать и улучшать уже работающие решения.
Менеджеру будет комфортнее работать с крутыми мотивированными людьми, которые сами разбираются в том, что нужно сделать, предлагают решения, понимают друг друга с полуслова и общаются с другими отделами. Но какая от этого польза бизнесу, если сейчас команда не такая? Важнее то, что менеджер понимает, что делать сейчас, чтобы команда становилась лучше.
В общем, если знаете, как нужно было делать – классно. Сейчас то что делать?
Признавайтесь, сколько раз вы понимали, что вокруг вас всё сделано неправильно, а вы то точно знали, как нужно было делать? Процессы не те и вот если бы вы участвовали в их формировании – точно всё работало бы лучше. Код – ужасное легаси и вообще надо было другие технологии использовать. Работать вам приходится с некомпетентными людьми, но вот если бы вы занимались наймом – наняли бы правильных.
Проблема в том, что ретроспективно судить конечно проще (снова привет, когнитивные искажения). Ведь так не видно, как конечный продукт (команда, код, процесс) оказался в этой точке, какие решения и кем были приняты, какие были условия и ограничения. Но важнее другое: ценность людей для бизнеса не в знании, «как нужно было сделать», а в действиях здесь и сейчас.
Конечно, разработчику удобнее работать в неспешном темпе, когда есть время спроектировать сложную систему и всегда есть время на технический долг. Но ценным его делает умение понять требования бизнеса и в нужной ситуации наговнокодить, а в другой заложить время на проектирование и реализацию гибкой и стабильной системы. Так же как и умение не только писать проект хорошо с нуля, но и поддерживать и улучшать уже работающие решения.
Менеджеру будет комфортнее работать с крутыми мотивированными людьми, которые сами разбираются в том, что нужно сделать, предлагают решения, понимают друг друга с полуслова и общаются с другими отделами. Но какая от этого польза бизнесу, если сейчас команда не такая? Важнее то, что менеджер понимает, что делать сейчас, чтобы команда становилась лучше.
В общем, если знаете, как нужно было делать – классно. Сейчас то что делать?
Поучаствовал в создании небольшого тренажера для проджект-менеджеров вместе со @skillsetter. Если у вас всё давно идеально работает и своих проблем не хватает – попробуйте решить чужие кейсы;)
👉 Тренажер
👉 Тренажер
skillsetter.io
Тестовые задания по проджект-менеджменту: тренажер для подготовки к собеседованию
Тестовые задания для проджект менеджера: кейсы, которые дают менеджерам IT-проектов на собеседовании. Задания на эстимейт проекта, решение конфликтов и проведение kick-off.
👍1
Про крутышей
Недавно на сессии менторства меня спросили – что отличает senior разработчиков? Одна из моих идей в том, что крутыши в своём деле не просто умеют что-то делать, а делают стабильно круто.
У вас же наверняка есть люди в окружении, которые вне зависимости от условий в 99% случаев делают качественно? И не важно, какие дедлайны, какая команда, какой уровень неопределенности в задаче, какие инструменты они будут использовать – результат точно будет крутым.
Конечно, этот скилл можно декомпозировать и говорить, что синьоров отличает насмотренность, опыт в конкретных технологиях или инструментах, глубокое погружение в задачи, стратегическое мышление, но в итоге всё сложится именно в стабильно крутые результаты. В общем, синьорность – это про марафон, а не спринт. Помните про людей, которые могут сделать хорошо, а есть те, которые не могут делать плохо?
В общем, задумываетесь, что вам нужно прокачивать, чтобы вырасти? Подумайте, что вам в последнее время мешало делать стабильно классно – это и есть зона роста.
P.S. Кстати, записывайтесь ко мне на менторство через getmentor. Личные консультации пока бесплатные!
Недавно на сессии менторства меня спросили – что отличает senior разработчиков? Одна из моих идей в том, что крутыши в своём деле не просто умеют что-то делать, а делают стабильно круто.
У вас же наверняка есть люди в окружении, которые вне зависимости от условий в 99% случаев делают качественно? И не важно, какие дедлайны, какая команда, какой уровень неопределенности в задаче, какие инструменты они будут использовать – результат точно будет крутым.
Конечно, этот скилл можно декомпозировать и говорить, что синьоров отличает насмотренность, опыт в конкретных технологиях или инструментах, глубокое погружение в задачи, стратегическое мышление, но в итоге всё сложится именно в стабильно крутые результаты. В общем, синьорность – это про марафон, а не спринт. Помните про людей, которые могут сделать хорошо, а есть те, которые не могут делать плохо?
В общем, задумываетесь, что вам нужно прокачивать, чтобы вырасти? Подумайте, что вам в последнее время мешало делать стабильно классно – это и есть зона роста.
P.S. Кстати, записывайтесь ко мне на менторство через getmentor. Личные консультации пока бесплатные!
Т.к. у меня в канале много продактов и разработчиков мобильных приложений, поделюсь анонсом. Мы в Appbooster делаем сервис для проверки продуктовых гипотез в мобильных приложениях Proba. С его помощью можно запускать A/B-тесты, а мы будем использовать байесовскую статистику, чтобы оптимизировать трафик под выбранную целевую метрику (например, конверсии или ARPU).
Cегодня команда проекта приглашает всех желающих на бесплатный вебинар «А/B-тесты в мобайле: как проверять гипотезы быстро и дешево».
Сегодня, 1 декабря в 16:00 МСК. Регистрация доступна здесь.
Cегодня команда проекта приглашает всех желающих на бесплатный вебинар «А/B-тесты в мобайле: как проверять гипотезы быстро и дешево».
Сегодня, 1 декабря в 16:00 МСК. Регистрация доступна здесь.
Про сложность и размер
В универе я получил один абсолютно бесполезный для современного мира навык: писать много и говорить сложно. Ведь если ты пишешь курсовую, реферат или диплом – у тебя обязательно есть ограничение по количеству страниц. Если объяснить свою мысль на паре листов А4, используя формулировки, которые поймут даже дети – тебя обязательно пошлют переделывать, ведь это не серьезно. Такой вот анти-метод Фейнмана.
Но в реальном, не академическом мире, у всех куча дел и людям просто некогда читать ваши портянки. Если захотите что-то рассказать соседнему отделу и напишете для этого длинное сообщение – его просто не дочитают. Если вы сложно объясните свою идею команде/руководителю – с большой вероятностью её не возьмут в работу.
Ещё из разработки я запомнил: если код получается слишком сложный – мы делаем что-то не так. Причем иногда проблема где-то на другом этапе, не в коде (а в проектировании, в дизайне, в самой идее новой фичи). Этот триггер можно использовать для всего: если у вас получается сложный/непонятный процесс, письмо, отчёт – в нём что-то не так, надо порефакторить.
В общем, хотите повысить конверсию людей в действия? Не отнимайте у них много времени и объясняйте проще, что вы от них хотите.
В универе я получил один абсолютно бесполезный для современного мира навык: писать много и говорить сложно. Ведь если ты пишешь курсовую, реферат или диплом – у тебя обязательно есть ограничение по количеству страниц. Если объяснить свою мысль на паре листов А4, используя формулировки, которые поймут даже дети – тебя обязательно пошлют переделывать, ведь это не серьезно. Такой вот анти-метод Фейнмана.
Но в реальном, не академическом мире, у всех куча дел и людям просто некогда читать ваши портянки. Если захотите что-то рассказать соседнему отделу и напишете для этого длинное сообщение – его просто не дочитают. Если вы сложно объясните свою идею команде/руководителю – с большой вероятностью её не возьмут в работу.
Ещё из разработки я запомнил: если код получается слишком сложный – мы делаем что-то не так. Причем иногда проблема где-то на другом этапе, не в коде (а в проектировании, в дизайне, в самой идее новой фичи). Этот триггер можно использовать для всего: если у вас получается сложный/непонятный процесс, письмо, отчёт – в нём что-то не так, надо порефакторить.
В общем, хотите повысить конверсию людей в действия? Не отнимайте у них много времени и объясняйте проще, что вы от них хотите.
Про проактивность
Многие компании и менеджеры топят за то, что нужно нанимать проактивных людей. А что это такое – мало кто говорит. Поделюсь своим мнением: проактивность – это не работать ради работы. Не работать больше часов, чем ожидается. Это не наводить суету вокруг. Это даже не делать больше, чем нужно. Проактивность - это видеть проблемы и придумывать их решения. Но не ваши проблемы, а проблемы бизнеса, коллег, менеджера, клиентов. Это понимать, что нужно людям и давать им это.
Приятным бонусом к проактивности идёт свобода действий:
– Если разработчик рассказывает, что он делает и какие у него проблемы – менеджеры не докучают ему вопросом «ну че, когда будет готово?».
– Если менеджер предоставляет руководителю в отчете всю нужную информацию о проекте/команде – руководитель не будет навязывать свой формат отчёта или процесс, его проблему уже решили.
– Если разработчик пишет код для других разработчиков, а не для машины, заботится о читаемости и объясняет непонятные места – ему не нужно тратить время на ответы другим разработчиком во время ревью, а апрув он получает быстрее.
– Если дизайнер объяснил свою идею текстом/стикерами/схемами на макетах, а не просто скинул картинки – команде не придётся назначать звонок «обсуждаем новые макеты», а дизайнер этот час времени будет заниматься любимыми делами.
В любом разговоре про проактивность никуда без байки про барина и работников. Знаю, вы пойдёте гуглить, так что сэкономлю ваше время:
Приходит работник к барину и говорит: «Барин, скажи, почему ты Семёну такому же работнику платишь 5 рублей в день всегда, а мне только 5 копеек?». Барин говорит: «Садись, сейчас объясню. Ой, смотри, за окном телега едет. Сбегай и спроси, не сено ли везут». Работник сбегал и говорит: «Да, сено везут». Барин опять говорит: «А ты спросил с каких лугов везут? С Семёновских?». Работник: «Не знаю». Барин: «Ну, сходи спроси». Работник сходил. Пришёл и говорит: «С Семёновских». Барин опять спрашивает: «А какой покос? Первый или второй?». Работник опять побежал спрашивать. Пришёл и ответил, что первый. Барин опять: «Почем они будут продавать?». Работник опять не знал ответа на этот вопрос. Хотел бежать спрашивать.*
В этот момент заходит Семён и говорит: «Барин, там сено везут с Семёновских лугов первого покоса, стоит 5 рублей, но я уже сторговался на 3. И пока телегу завернул, она стоит в нашем дворе. Что дальше делать будем?».
В общем, будьте как Семён. Качайте проактивность.
Многие компании и менеджеры топят за то, что нужно нанимать проактивных людей. А что это такое – мало кто говорит. Поделюсь своим мнением: проактивность – это не работать ради работы. Не работать больше часов, чем ожидается. Это не наводить суету вокруг. Это даже не делать больше, чем нужно. Проактивность - это видеть проблемы и придумывать их решения. Но не ваши проблемы, а проблемы бизнеса, коллег, менеджера, клиентов. Это понимать, что нужно людям и давать им это.
Приятным бонусом к проактивности идёт свобода действий:
– Если разработчик рассказывает, что он делает и какие у него проблемы – менеджеры не докучают ему вопросом «ну че, когда будет готово?».
– Если менеджер предоставляет руководителю в отчете всю нужную информацию о проекте/команде – руководитель не будет навязывать свой формат отчёта или процесс, его проблему уже решили.
– Если разработчик пишет код для других разработчиков, а не для машины, заботится о читаемости и объясняет непонятные места – ему не нужно тратить время на ответы другим разработчиком во время ревью, а апрув он получает быстрее.
– Если дизайнер объяснил свою идею текстом/стикерами/схемами на макетах, а не просто скинул картинки – команде не придётся назначать звонок «обсуждаем новые макеты», а дизайнер этот час времени будет заниматься любимыми делами.
В любом разговоре про проактивность никуда без байки про барина и работников. Знаю, вы пойдёте гуглить, так что сэкономлю ваше время:
Приходит работник к барину и говорит: «Барин, скажи, почему ты Семёну такому же работнику платишь 5 рублей в день всегда, а мне только 5 копеек?». Барин говорит: «Садись, сейчас объясню. Ой, смотри, за окном телега едет. Сбегай и спроси, не сено ли везут». Работник сбегал и говорит: «Да, сено везут». Барин опять говорит: «А ты спросил с каких лугов везут? С Семёновских?». Работник: «Не знаю». Барин: «Ну, сходи спроси». Работник сходил. Пришёл и говорит: «С Семёновских». Барин опять спрашивает: «А какой покос? Первый или второй?». Работник опять побежал спрашивать. Пришёл и ответил, что первый. Барин опять: «Почем они будут продавать?». Работник опять не знал ответа на этот вопрос. Хотел бежать спрашивать.*
В этот момент заходит Семён и говорит: «Барин, там сено везут с Семёновских лугов первого покоса, стоит 5 рублей, но я уже сторговался на 3. И пока телегу завернул, она стоит в нашем дворе. Что дальше делать будем?».
В общем, будьте как Семён. Качайте проактивность.
👍4
Про делегирование
1. Все задачи, которыми я занимаюсь очень важны. Я не могу от них отказываться.
2. Нужно быть очень ответственным, чтобы их выполнять. У нас пока нет другого такого человека, кроме меня.
3. Описывать задачу и погружать другого человека в контекст дольше, чем сделать самому.
Какая из этих мыслей регулярно крутится у вас в голове? Если хотя бы одна из трёх – поздравляю, вам нужно учиться делегировать. Например, почитать гайд от @skillsetter, в котором я поделился полезным лайфхаком:
Делегирование задач: зачем это делать, как правильно и что мешает
Кстати, если у вас есть свои лайфхаки или инструменты делегирования – закидывайте в комменты.
1. Все задачи, которыми я занимаюсь очень важны. Я не могу от них отказываться.
2. Нужно быть очень ответственным, чтобы их выполнять. У нас пока нет другого такого человека, кроме меня.
3. Описывать задачу и погружать другого человека в контекст дольше, чем сделать самому.
Какая из этих мыслей регулярно крутится у вас в голове? Если хотя бы одна из трёх – поздравляю, вам нужно учиться делегировать. Например, почитать гайд от @skillsetter, в котором я поделился полезным лайфхаком:
Делегирование задач: зачем это делать, как правильно и что мешает
Кстати, если у вас есть свои лайфхаки или инструменты делегирования – закидывайте в комменты.
Telegram
skillsetter.io
Про кар'єру в IT, запуск і зростання продуктів.
❤1
Про правильные привычки в разработке
Разработка – командная дисциплина, где важен не только код и результат, но и процесс. Поэтому для разработчиков полезно вырабатывать правильные привычки. Попробовал сформулировать 5 таких привычек, которые упростят жизнь всем вокруг:
1. Работать прозрачно
2. Двигаться по чуть-чуть
3. Говорить просто
4. Делать скучно
5. Соблюдать баланс
Подробности про каждый принцип - в статье, которуя я написал для @skillbox_media_code
Разработка – командная дисциплина, где важен не только код и результат, но и процесс. Поэтому для разработчиков полезно вырабатывать правильные привычки. Попробовал сформулировать 5 таких привычек, которые упростят жизнь всем вокруг:
1. Работать прозрачно
2. Двигаться по чуть-чуть
3. Говорить просто
4. Делать скучно
5. Соблюдать баланс
Подробности про каждый принцип - в статье, которуя я написал для @skillbox_media_code
Новый год в канале решил начать с подведения итогов предыдущего, а с вами поделюсь постами за прошлый год, которые собрали больше всего пересылок. Будет полезно для недавно подписавшихся:
1. Time-to метрики
2. Что развивать лидеру?
3. Про неопределённость
4. Про проактивность
5. Про объяснения
1. Time-to метрики
2. Что развивать лидеру?
3. Про неопределённость
4. Про проактивность
5. Про объяснения
Telegram
Saturday Night Hack
Time-to метрики
Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product…
Все знают про метрику time-to-market, которая по-сути отражает скорость разработки. Чем медленнее мы будем выкатывать гипотезы – тем с большей вероятностью нас обгонят конкуренты или мы просто потратим все деньги на команду и не найдём product…
Про детализацию информации
Мечтаю о таком приложении, которое позволит изменять детализацию в любом потоке информации.
– Вернулся в интернет после месячного ретрита? Оно расскажет за 5 минут только о главных событиях (вы же не хотите читать весь твиттер за месяц и листать все новости?)
– Читаешь лонгрид на больную тему? Ставишь максимум детализации. Просто интересены шаги и выводы или мало времени? Двигаешь ползунок влево – в тексте пропадает вся литература и авторский стиль и остаются только факты.
– Интересно, как дела сейчас в компании? Видишь дашборд только с основными цифрами. За что-то зацепился глаз? Провалились в конкретную команду или проект, повысили детализацию и смотрим цифры, результаты и какие возникали проблемы.
Но пока управлять потоками информации могут только люди и важно понимать, кому и какой уровень детализации необходим. Внутри команды люди хотят понимать, чем они будут заниматься на этой неделе, где взять необходимые доступы и найти прототипы экранов. Соседняя команда хочет видеть, как продвигаются задачи, которые они просили делать. Руководители – понимать, приближаемся ли мы к поставленным целям. А если долго не приближаемся – «провалиться» в детали, найти, что пошло не так и помочь исправить это.
В общем, одна и та же информация должна выглядеть по-разному для разных людей и их контекста. Одних не нужно перегружать лишней информаций, а другим наоборот, нужно дать все мельчайшие детали.
Мечтаю о таком приложении, которое позволит изменять детализацию в любом потоке информации.
– Вернулся в интернет после месячного ретрита? Оно расскажет за 5 минут только о главных событиях (вы же не хотите читать весь твиттер за месяц и листать все новости?)
– Читаешь лонгрид на больную тему? Ставишь максимум детализации. Просто интересены шаги и выводы или мало времени? Двигаешь ползунок влево – в тексте пропадает вся литература и авторский стиль и остаются только факты.
– Интересно, как дела сейчас в компании? Видишь дашборд только с основными цифрами. За что-то зацепился глаз? Провалились в конкретную команду или проект, повысили детализацию и смотрим цифры, результаты и какие возникали проблемы.
Но пока управлять потоками информации могут только люди и важно понимать, кому и какой уровень детализации необходим. Внутри команды люди хотят понимать, чем они будут заниматься на этой неделе, где взять необходимые доступы и найти прототипы экранов. Соседняя команда хочет видеть, как продвигаются задачи, которые они просили делать. Руководители – понимать, приближаемся ли мы к поставленным целям. А если долго не приближаемся – «провалиться» в детали, найти, что пошло не так и помочь исправить это.
В общем, одна и та же информация должна выглядеть по-разному для разных людей и их контекста. Одних не нужно перегружать лишней информаций, а другим наоборот, нужно дать все мельчайшие детали.
👍30❤1