Парадокс покоя
Отметил для себя парадокс: чем спокойнее работа команды, тем хуже результат. Чаще всего у вас проблемы, если:
– Никто не спорит и все согласны со всеми принимаемыми решениями
– Все уверены, что выстроены идеальные процессы и коммуникация
– Никто не сомневается в компетентности других членов команды, в качестве их работы
– Команда годами использует одни и те же инструменты и практики
И наоборот: чем больше вопросов, сомнений, дискуссий и изменений – тем быстрее достигаются крутые результаты.
Отметил для себя парадокс: чем спокойнее работа команды, тем хуже результат. Чаще всего у вас проблемы, если:
– Никто не спорит и все согласны со всеми принимаемыми решениями
– Все уверены, что выстроены идеальные процессы и коммуникация
– Никто не сомневается в компетентности других членов команды, в качестве их работы
– Команда годами использует одни и те же инструменты и практики
И наоборот: чем больше вопросов, сомнений, дискуссий и изменений – тем быстрее достигаются крутые результаты.
Как отличить инженера от программиста?
– Программист скажет «так сделать нельзя», инженер возьмёт паузу и придёт либо с решением, либо с альтернативой
– Программист скажет «я там спросил, а мне не ответили...», «пул-реквест на код-ревью/QA-завис...», «у меня доступов не было...», а инженер доведёт всё до продакшена
– Программист скажет «у меня кончились задачки, чем заняться?», инженер – «задачки кончились, но у меня есть пара сотен предложений. Займусь ими?»
– Программист делает как попросили, инженер – лучше
– Программист начнёт делать, когда поймёт, что от него хотят. Инженер - когда поймёт, зачем
Нанимайте инженеров!
– Программист скажет «так сделать нельзя», инженер возьмёт паузу и придёт либо с решением, либо с альтернативой
– Программист скажет «я там спросил, а мне не ответили...», «пул-реквест на код-ревью/QA-завис...», «у меня доступов не было...», а инженер доведёт всё до продакшена
– Программист скажет «у меня кончились задачки, чем заняться?», инженер – «задачки кончились, но у меня есть пара сотен предложений. Займусь ими?»
– Программист делает как попросили, инженер – лучше
– Программист начнёт делать, когда поймёт, что от него хотят. Инженер - когда поймёт, зачем
Нанимайте инженеров!
Как прокачать руководителя?
Фидбек между руководителем и подчинённым работает в обе стороны. Почему-то об этом часто забывают сами подчинённые и воспринимают общение с руководителем, только как получение фидбека. Но (сюрприз!) руководители – просто люди. У них может не хватать опыта, могут быть проблемы с тайм-менеджментом, они могут не знать, о чём вы хотите поговорить, у них у самих может быть не лучший руководитель. А ещё они сами могут всего этого не замечать. Так что если вы не получаете от руководителя того, что ожидаете – возьмите инициативу в свои руки, прежде чем искать новую работу. В английском для этого есть отличное выражение – manage your manager.
Примеры распространённых ситуаций:
– Получаете только негативный фидбек? Соберите факты и обсудите. Вроде «мне кажется, что за последние 3 месяца я хорошо сделал X и Y, но слышал только критику за Z. Почему?»
– Руководитель становится бутылочным горлышком и это замедляет вас? Намекните, что вы могли бы быстрее и лучше делать свою работу, если бы он делегировал полномочия
– Руководитель назначает встречи в стиле «окей, давай вернёмся к этому вопросу через месяц» и забывает о них? Добавляйте в календарь и приглашайте его. Либо просто напоминайте – «Привет! Месяц прошел – обсудим?»
– Не знаете, как зарабатывать больше? Спросите руководителя. Подумайте вместе, что вы можете делать и обсудите дату подведения промежуточных итогов
– Вам обычно не хочется с ним разговаривать? Скорее всего вам не повезло и вы работаете с руководителем, который не заряжает вас энергией, а забирает её. Попробуйте решать вопросы письменно – может так будет проще.
Умение работать с «плохим» начальником нужно в первую очередь вам, чтобы создавать комфортные для себя условия в любой компании. А проблемы будут у любого менеджера
Фидбек между руководителем и подчинённым работает в обе стороны. Почему-то об этом часто забывают сами подчинённые и воспринимают общение с руководителем, только как получение фидбека. Но (сюрприз!) руководители – просто люди. У них может не хватать опыта, могут быть проблемы с тайм-менеджментом, они могут не знать, о чём вы хотите поговорить, у них у самих может быть не лучший руководитель. А ещё они сами могут всего этого не замечать. Так что если вы не получаете от руководителя того, что ожидаете – возьмите инициативу в свои руки, прежде чем искать новую работу. В английском для этого есть отличное выражение – manage your manager.
Примеры распространённых ситуаций:
– Получаете только негативный фидбек? Соберите факты и обсудите. Вроде «мне кажется, что за последние 3 месяца я хорошо сделал X и Y, но слышал только критику за Z. Почему?»
– Руководитель становится бутылочным горлышком и это замедляет вас? Намекните, что вы могли бы быстрее и лучше делать свою работу, если бы он делегировал полномочия
– Руководитель назначает встречи в стиле «окей, давай вернёмся к этому вопросу через месяц» и забывает о них? Добавляйте в календарь и приглашайте его. Либо просто напоминайте – «Привет! Месяц прошел – обсудим?»
– Не знаете, как зарабатывать больше? Спросите руководителя. Подумайте вместе, что вы можете делать и обсудите дату подведения промежуточных итогов
– Вам обычно не хочется с ним разговаривать? Скорее всего вам не повезло и вы работаете с руководителем, который не заряжает вас энергией, а забирает её. Попробуйте решать вопросы письменно – может так будет проще.
Умение работать с «плохим» начальником нужно в первую очередь вам, чтобы создавать комфортные для себя условия в любой компании. А проблемы будут у любого менеджера
Слова паразиты, часть 6
– Ну я же говорил!
У всех хотя бы иногда проскакивает эта фраза, хоть и не все озвучивают её вслух. И именно когда она попадает в мозг – нужно себя поймать и разобраться, в чём же первопричина? В 80% случаев произошло что-то, что не идёт на пользу команде. Например:
– Вы закинули идею, возможно в формате «а давайте...», но не захотели её продвигать, чтобы умышленно избежать ответственности за возможные последствия. Возможно ожидая, что кто-то её услышит и «возьмёт в работу» вместо вас, но этого не произошло и всем от этого стало хуже.
– Недостаточно аргументов. Возможно, вы уверены что ваше предложение было очевидно остальным (несмотря на то, что их позиция для вас не очевидна) и из-за недостаточной аргументации, вашего неумения «продавать» свои идеи пострадала вся команда.
– Ваше эго для вас важнее общих успехов
– Вы просто любите покой и не хотите с кем-то спорить.
– Из нескольких альтернатив выбрали не ваше решение, хоть вы и аргументировали всё и были готовы взять ответственность. Можете даже не напоминать – в следующий раз все и так вспомнят этот случай и прислушаются к вам.
Узнали себя? Ну я же говорил!
– Ну я же говорил!
У всех хотя бы иногда проскакивает эта фраза, хоть и не все озвучивают её вслух. И именно когда она попадает в мозг – нужно себя поймать и разобраться, в чём же первопричина? В 80% случаев произошло что-то, что не идёт на пользу команде. Например:
– Вы закинули идею, возможно в формате «а давайте...», но не захотели её продвигать, чтобы умышленно избежать ответственности за возможные последствия. Возможно ожидая, что кто-то её услышит и «возьмёт в работу» вместо вас, но этого не произошло и всем от этого стало хуже.
– Недостаточно аргументов. Возможно, вы уверены что ваше предложение было очевидно остальным (несмотря на то, что их позиция для вас не очевидна) и из-за недостаточной аргументации, вашего неумения «продавать» свои идеи пострадала вся команда.
– Ваше эго для вас важнее общих успехов
¯\_(ツ)_/¯. Если из 10 принятых чужих решений лишь одно не сработает вы наверняка скажете заветную фразу, а про остальные 9 и не вспомните– Вы просто любите покой и не хотите с кем-то спорить.
– Из нескольких альтернатив выбрали не ваше решение, хоть вы и аргументировали всё и были готовы взять ответственность. Можете даже не напоминать – в следующий раз все и так вспомнят этот случай и прислушаются к вам.
Узнали себя? Ну я же говорил!
Как давать фидбек?
Нет-нет, я тут не буду говорить про схемы бутерброда, ненасильственного общения или stop–start-continue. Тут о другом.
Часто замечаю 2 крайности при фидбеке о чужой работе:
1. Люди смотрят на чужую работу (код, картинки, тексты) и никак её не комментируют, если их явно об этом не спросить.
При такой схеме в команде отсутствует культура обмена знаниями и мнениями. «Ну работает и работает» и не важно, что это можно сделать проще/быстрее/лучше, часто даже не потратив больше времени.
2. Чаще всего бывает в схеме лид/подчинённый: одни комментируют всё подряд, выражая своё мнение о каждой мелочи, после чего другие исправляют всё и делают именно так, как сказали.
При отсутствии диалога исполнитель не берёт на себя ответственность и полностью перекладывает её на ревьюера. И тратит сильно больше времени, т.к. часть комментариев незначительны, но он всё равно их исправляет.
Решение – фидбек в стиле ревью на гитхабе, где ты можешь добавить любые комментарии, а в итоге необходимо явно обозначить, как воспринимать твой фидбек – это просто комментарий, апрув работы или просьба переделать?
Итого, 5 простых правил для продуктивного фидбека (и не важно, кто ты – новичок в стартапе или CEO в большой компании):
1. Задавай вопросы. Так будешь лучше понимать, что происходит, почему именно так и вообще, как мыслят другие
2. Предлагай идеи, желательно как-то аргументируя (даже если ты не считаешь себя экспертом в вопросе). Не все знают, что знаешь ты и кто-то точно чему-то научится.
3. Пиши о возможных проблемах и альтернативных путях решения
4. Хвали коллег, когда они делают хорошо!
5. И главное – явно сообщи, что ты хочешь? Как относиться к твоему фидбеку – это просто комментарий, просьба переделать или твоё мнение, что всё ок и с этим можно продолжать?
Ну и примеры:
– «̶Д̶а̶в̶а̶й̶ ̶п̶о̶ ̶н̶о̶в̶о̶й̶,̶ ̶М̶и̶ш̶а̶,̶ ̶в̶с̶е̶ ̶х̶е̶р̶н̶я̶!̶»̶ ̶«Давай поправим пункты 3-5 и будет 👍, а 6-7 на твоё усмотрение, не хочется время терять»
– «👀 Накидал комментов, на случай если интересно моё мнение»
– «🔫 Пушка, можно релизить!»
Нет-нет, я тут не буду говорить про схемы бутерброда, ненасильственного общения или stop–start-continue. Тут о другом.
Часто замечаю 2 крайности при фидбеке о чужой работе:
1. Люди смотрят на чужую работу (код, картинки, тексты) и никак её не комментируют, если их явно об этом не спросить.
При такой схеме в команде отсутствует культура обмена знаниями и мнениями. «Ну работает и работает» и не важно, что это можно сделать проще/быстрее/лучше, часто даже не потратив больше времени.
2. Чаще всего бывает в схеме лид/подчинённый: одни комментируют всё подряд, выражая своё мнение о каждой мелочи, после чего другие исправляют всё и делают именно так, как сказали.
При отсутствии диалога исполнитель не берёт на себя ответственность и полностью перекладывает её на ревьюера. И тратит сильно больше времени, т.к. часть комментариев незначительны, но он всё равно их исправляет.
Решение – фидбек в стиле ревью на гитхабе, где ты можешь добавить любые комментарии, а в итоге необходимо явно обозначить, как воспринимать твой фидбек – это просто комментарий, апрув работы или просьба переделать?
Итого, 5 простых правил для продуктивного фидбека (и не важно, кто ты – новичок в стартапе или CEO в большой компании):
1. Задавай вопросы. Так будешь лучше понимать, что происходит, почему именно так и вообще, как мыслят другие
2. Предлагай идеи, желательно как-то аргументируя (даже если ты не считаешь себя экспертом в вопросе). Не все знают, что знаешь ты и кто-то точно чему-то научится.
3. Пиши о возможных проблемах и альтернативных путях решения
4. Хвали коллег, когда они делают хорошо!
5. И главное – явно сообщи, что ты хочешь? Как относиться к твоему фидбеку – это просто комментарий, просьба переделать или твоё мнение, что всё ок и с этим можно продолжать?
Ну и примеры:
– «̶Д̶а̶в̶а̶й̶ ̶п̶о̶ ̶н̶о̶в̶о̶й̶,̶ ̶М̶и̶ш̶а̶,̶ ̶в̶с̶е̶ ̶х̶е̶р̶н̶я̶!̶»̶ ̶«Давай поправим пункты 3-5 и будет 👍, а 6-7 на твоё усмотрение, не хочется время терять»
– «👀 Накидал комментов, на случай если интересно моё мнение»
– «🔫 Пушка, можно релизить!»
Видео про культуру в Spotify – это, наверное, лучшее куда вы можете потратить свободные 25 минут сегодня (и как это раньше прошло мимо меня?)
Основные тезисы:
- Команды должны быть loosely coupled, tighly aligned. Ставьте понятные цели для компании, чтобы команды шли в одном направлении, при этом делая команды максимально автономными
– No one will tell you what to do. Конкретные действия должны определяться внутри команд, но основываться на глобальных целях
– «If you need to know exactly who is making decisions you are in the wrong place». Избегайте систем, где решения принимаются единолично
– Чем реже релизы – тем сложнее релизить. И наоборот. Чаще делайте релизы, прячьте неготовый функционал за feature toggles, упрощайте процесс релиза.
– Каждая команда отвечает за свои системы и релизит их независимо от других команд
– Fail fast → learn fast → improve fast
– failure recovery важнее, чем failure avoidance
– «If everything is under control, you are going too slow»
- Innovation важнее predictability. 100% predictability = 0% innovation
– Big project = big risk. Делите большие проекты на мелкие шаги, выкатывайте MVP
Оно же текстом: часть 1, часть 2.
Основные тезисы:
- Команды должны быть loosely coupled, tighly aligned. Ставьте понятные цели для компании, чтобы команды шли в одном направлении, при этом делая команды максимально автономными
– No one will tell you what to do. Конкретные действия должны определяться внутри команд, но основываться на глобальных целях
– «If you need to know exactly who is making decisions you are in the wrong place». Избегайте систем, где решения принимаются единолично
– Чем реже релизы – тем сложнее релизить. И наоборот. Чаще делайте релизы, прячьте неготовый функционал за feature toggles, упрощайте процесс релиза.
– Каждая команда отвечает за свои системы и релизит их независимо от других команд
– Fail fast → learn fast → improve fast
– failure recovery важнее, чем failure avoidance
– «If everything is under control, you are going too slow»
- Innovation важнее predictability. 100% predictability = 0% innovation
– Big project = big risk. Делите большие проекты на мелкие шаги, выкатывайте MVP
Оно же текстом: часть 1, часть 2.
Про поведение
Нашел простую модель, объясняющую человеческое поведение. Fogg Behavior Model говорит, что поведение зависит от мотивации, сложности этого действия и побуждений:
Как это применять в командах? Так же как и в продуктах/дизайне: если хотите, чтобы люди что-то делали, то
– Упрощайте. Чем проще и понятнее взаимодействие, инструменты, процессы – тем проще их использовать. Плохо: деплой в особую фазу меркурия специально выбранным человеком с помощью сложных ритуалов. Хорошо: деплой одним нажатием на кнопку 🆗.
– Мотивируйте. Мало рассказать, как надо делать, важно показать пользу для конкретного человека. Плохо: «Ну показывай, что сделал». Хорошо: «Чем раньше ты поделишься наработками – тем быстрее получишь фидбек и в случае ошибок или неверного решения не обидно будет срезать часть работы 🔪»
– Подталкивайте. Даже если люди замотивированы что-то сделать и у них есть все возможности – им нужен call to action. Плохо: «Стыдно этого не знать...», хорошо: «Почитай <название книги> – там классно рассказывается про базовые принципы, тебе в будущем это поможет быстрее принимать решения 💪»
Почитать:
– https://suebehaviouraldesign.com/bj-fogg-model/
– https://behaviormodel.org
Нашел простую модель, объясняющую человеческое поведение. Fogg Behavior Model говорит, что поведение зависит от мотивации, сложности этого действия и побуждений:
Behavior = motivation × ability × promptКак это применять в командах? Так же как и в продуктах/дизайне: если хотите, чтобы люди что-то делали, то
– Упрощайте. Чем проще и понятнее взаимодействие, инструменты, процессы – тем проще их использовать. Плохо: деплой в особую фазу меркурия специально выбранным человеком с помощью сложных ритуалов. Хорошо: деплой одним нажатием на кнопку 🆗.
– Мотивируйте. Мало рассказать, как надо делать, важно показать пользу для конкретного человека. Плохо: «Ну показывай, что сделал». Хорошо: «Чем раньше ты поделишься наработками – тем быстрее получишь фидбек и в случае ошибок или неверного решения не обидно будет срезать часть работы 🔪»
– Подталкивайте. Даже если люди замотивированы что-то сделать и у них есть все возможности – им нужен call to action. Плохо: «Стыдно этого не знать...», хорошо: «Почитай <название книги> – там классно рассказывается про базовые принципы, тебе в будущем это поможет быстрее принимать решения 💪»
Почитать:
– https://suebehaviouraldesign.com/bj-fogg-model/
– https://behaviormodel.org
Про хлам
Исторически сложилось, что движение вперёд – это всегда накопление. Ты копишь опыт, деньги, вещи, людей. Аналогично и в разработке: команда растёт, продукт обрастает новыми фичами, процессов и договорённостей всё больше, менеджерить всё это становится всё сложнее. И чаще всего эти проблемы решаются двумя путями: делать и держать в голове больше, либо нанимать людей, которые будут помогать дальше создавать новое. Есть третий, непопулярный, но иногда наиболее эффективный путь: избавляться от чего-то старого и ненужного.
Я всегда больше всего любил изменения в коде, в которых что-то удалялось и ничего не добавлялось. При этом ничего не ломалось и всё работало как и прежде, а код становился проще, а значит лучше.
От чего, например, можно избавиться и упростить жизнь себе и окружающим?
– От фич. Зачем добавили новую фичу в продукт? Принесла ли она пользу? Если нет – то может она и не нужна? Или, возможно, с её помощью вы решили те же проблемы, что пытались решить другими фичами и теперь можно удалить именно их и оставить только новую? Это можно сделать ритуалом, например выделять несколько часов каждую пятницу на поиск чего-то ненужного.
– От процессов. Ведь наверняка у вас есть какое-то соглашение принятое несколько лет назад, которое все делают по привычке, не задаваясь вопросом «зачем мы это делаем?». Докапайтесь до первопричин, например используя 5 whys и избавьтесь от неактуальных процессов.
– От кода. В проекте остался код, который уже не используется? Удаляйте. Будет нужен – вернёте с помощью гита (подсказка: минимум 80% удалённого кода окажутся ненужными). У вас же не используют количество строк кода, как метрику продуктивности?
– От чатов. Можно бороться с fomo и выходить из чатов, где не нужно постоянное присутствие.
– От сервисов/систем/софта. Иногда, чтобы система работала стабильнее её нужно упростить, а не добавлять новые элементы.
Хорошая практика (которой сложно придерживаться) – при создании чего-то нового избавляться от чего-то старого. Заводите новый регулярный митинг? Отмените один из старых. Добавляете новый код? Удалите немного старого.
В общем, как говорит каждый второй мотиватор – «выкидывайте хлам, чтобы освободить место для чего-то нового».
Исторически сложилось, что движение вперёд – это всегда накопление. Ты копишь опыт, деньги, вещи, людей. Аналогично и в разработке: команда растёт, продукт обрастает новыми фичами, процессов и договорённостей всё больше, менеджерить всё это становится всё сложнее. И чаще всего эти проблемы решаются двумя путями: делать и держать в голове больше, либо нанимать людей, которые будут помогать дальше создавать новое. Есть третий, непопулярный, но иногда наиболее эффективный путь: избавляться от чего-то старого и ненужного.
Я всегда больше всего любил изменения в коде, в которых что-то удалялось и ничего не добавлялось. При этом ничего не ломалось и всё работало как и прежде, а код становился проще, а значит лучше.
От чего, например, можно избавиться и упростить жизнь себе и окружающим?
– От фич. Зачем добавили новую фичу в продукт? Принесла ли она пользу? Если нет – то может она и не нужна? Или, возможно, с её помощью вы решили те же проблемы, что пытались решить другими фичами и теперь можно удалить именно их и оставить только новую? Это можно сделать ритуалом, например выделять несколько часов каждую пятницу на поиск чего-то ненужного.
– От процессов. Ведь наверняка у вас есть какое-то соглашение принятое несколько лет назад, которое все делают по привычке, не задаваясь вопросом «зачем мы это делаем?». Докапайтесь до первопричин, например используя 5 whys и избавьтесь от неактуальных процессов.
– От кода. В проекте остался код, который уже не используется? Удаляйте. Будет нужен – вернёте с помощью гита (подсказка: минимум 80% удалённого кода окажутся ненужными). У вас же не используют количество строк кода, как метрику продуктивности?
– От чатов. Можно бороться с fomo и выходить из чатов, где не нужно постоянное присутствие.
– От сервисов/систем/софта. Иногда, чтобы система работала стабильнее её нужно упростить, а не добавлять новые элементы.
Хорошая практика (которой сложно придерживаться) – при создании чего-то нового избавляться от чего-то старого. Заводите новый регулярный митинг? Отмените один из старых. Добавляете новый код? Удалите немного старого.
В общем, как говорит каждый второй мотиватор – «выкидывайте хлам, чтобы освободить место для чего-то нового».
Про слак, часть 1: личка
В офисе вы довольно редко начинаете обсуждение с фразы «пойдём в переговорку?», проще на месте всё обсудить. Ещё есть бонус – кто-то третий, сидящий рядом может услышать разговор и вклиниться, т.к. он обладает доп. информацией, которой нет у вас двоих. Но почему-то в чатах многие всё ещё предпочитают общение именно в личке. Одни сначала решают «ой, ну зачем я буду людей отвлекать?», а другие потом не понимают, как принимаются те или иные решения.
Если не обсуждаете конфиденциальные вопросы – обсуждайте их в общих чатах в тредах, даже если общаетесь вдвоём. Личка - это разговор 1:1 в переговорке.
В офисе вы довольно редко начинаете обсуждение с фразы «пойдём в переговорку?», проще на месте всё обсудить. Ещё есть бонус – кто-то третий, сидящий рядом может услышать разговор и вклиниться, т.к. он обладает доп. информацией, которой нет у вас двоих. Но почему-то в чатах многие всё ещё предпочитают общение именно в личке. Одни сначала решают «ой, ну зачем я буду людей отвлекать?», а другие потом не понимают, как принимаются те или иные решения.
Если не обсуждаете конфиденциальные вопросы – обсуждайте их в общих чатах в тредах, даже если общаетесь вдвоём. Личка - это разговор 1:1 в переговорке.
Про управление ожиданиями
Когда я начинал в разработке, я был уверен, что топовых специалистов отличает то, что они делают всё максимально качественно, со знанием дела, в поставленные им сроки и без ошибок. И именно такие работают в далёких яндексах, фейсбуках или стартапах из кремниевой долины. Но время шло, я работал в классных компаниях с высокооплачиваемыми разработчиками, менеджерами и дизайнерами. Работал в аутсорсе на США, стартапах на инвестициях, европейских энтерпрайзах и нигде не встречал их, которых когда-то рисовал у себя в голове. И тогда мне пришло 2 инсайта:
1. Все косячат
2. Это нормально
Иногда важнее не то, что и как вы делаете, а что от вас ожидают люди вокруг. Управление этими ожиданиями – это ваша задача. Это тот самый скилл, который отличает одного командного игрока, работой которого все всегда довольны от другого, у которого «всё не так». Поэтому
– Нормально совершать ошибки, не нормально не говорить о них. К компаниям, которые открыто говорят о своих сбоях обычно больше доверия, чем к тем, которые молча падают и потом просто говорят клиентам, что «у нас был сбой и мы всё пофиксили!». Можно даже написать увлекательный рассказ про вашу поломку, как гитлаб, например. Так же и в команде: если что-то «сломалось» в вашей работе – расскажите, что именно произошло, как вы всё «починили» и что сделали, чтобы это не повторялось – команда будет вам больше доверять.
– Нормально не успеть что-то в срок, не нормально не предупреждать об этом. Ведь заказчик (даже если он внутренний) ожидает результат и возможно строит дальнейшие планы исходя из этих сроков. И, кстати, сделать больше/лучше оговорённого – это приятный бонус, но не причина промолчать.
– Нормально делать что-то неидеально. Сделали версию приложения с ограничениями? Расскажите о них тому, кто будет его тестировать. Не стали писать тесты к коду, потому что нужно срочно выкатить фикс? Пусть другие разработчики знают об этом и не думают, что вы забыли. Половина успешных проектов начинались с наколеночной версии
– Нормально чего-то не знать или не уметь. И нормально идти и разбираться, пробовать что-то новое и внедрять это, а не ждать, пока найдётся «эксперт».
– Но ненормально нарушать сроки регулярно, повторять ошибки и не учиться тому, что нужно людям вокруг.
Одна из проблем с управлением ожиданиями – повсеместный синдром самозванца в IT. Ведь стыдно признаваться людям вокруг в своих ошибках и рассказывать, что ты чего-то не знаешь, когда для тебя самого это дискомфорт. Хорошее упражнение – просто начать публично говорить о том, чего вы не знаете. Смотрите, например, как делает Никита
Когда я начинал в разработке, я был уверен, что топовых специалистов отличает то, что они делают всё максимально качественно, со знанием дела, в поставленные им сроки и без ошибок. И именно такие работают в далёких яндексах, фейсбуках или стартапах из кремниевой долины. Но время шло, я работал в классных компаниях с высокооплачиваемыми разработчиками, менеджерами и дизайнерами. Работал в аутсорсе на США, стартапах на инвестициях, европейских энтерпрайзах и нигде не встречал их, которых когда-то рисовал у себя в голове. И тогда мне пришло 2 инсайта:
1. Все косячат
2. Это нормально
Иногда важнее не то, что и как вы делаете, а что от вас ожидают люди вокруг. Управление этими ожиданиями – это ваша задача. Это тот самый скилл, который отличает одного командного игрока, работой которого все всегда довольны от другого, у которого «всё не так». Поэтому
– Нормально совершать ошибки, не нормально не говорить о них. К компаниям, которые открыто говорят о своих сбоях обычно больше доверия, чем к тем, которые молча падают и потом просто говорят клиентам, что «у нас был сбой и мы всё пофиксили!». Можно даже написать увлекательный рассказ про вашу поломку, как гитлаб, например. Так же и в команде: если что-то «сломалось» в вашей работе – расскажите, что именно произошло, как вы всё «починили» и что сделали, чтобы это не повторялось – команда будет вам больше доверять.
– Нормально не успеть что-то в срок, не нормально не предупреждать об этом. Ведь заказчик (даже если он внутренний) ожидает результат и возможно строит дальнейшие планы исходя из этих сроков. И, кстати, сделать больше/лучше оговорённого – это приятный бонус, но не причина промолчать.
– Нормально делать что-то неидеально. Сделали версию приложения с ограничениями? Расскажите о них тому, кто будет его тестировать. Не стали писать тесты к коду, потому что нужно срочно выкатить фикс? Пусть другие разработчики знают об этом и не думают, что вы забыли. Половина успешных проектов начинались с наколеночной версии
– Нормально чего-то не знать или не уметь. И нормально идти и разбираться, пробовать что-то новое и внедрять это, а не ждать, пока найдётся «эксперт».
– Но ненормально нарушать сроки регулярно, повторять ошибки и не учиться тому, что нужно людям вокруг.
Одна из проблем с управлением ожиданиями – повсеместный синдром самозванца в IT. Ведь стыдно признаваться людям вокруг в своих ошибках и рассказывать, что ты чего-то не знаешь, когда для тебя самого это дискомфорт. Хорошее упражнение – просто начать публично говорить о том, чего вы не знаете. Смотрите, например, как делает Никита
+5% к качеству
Вам когда нибудь приходило пуш-уведомление от больших серьезных приложений с текстом «hey» или «test»? Мне за последние несколько лет раз 5 точно.
А всё потому, что кто-то при тестировании поленился подумать, а что же на самом деле будут слать пользователям? Чтобы не попадать в такие ситуации, есть простое правило – всегда использовать реальные данные. Оно работает для всех: продакты, дизайнеры, разработчики, QA... И дальше – продажники, маркетологи, контент-менеджеры и даже HR.
– Рассылаете тестовую email-рассылку или пуш? Даже если отправляете его только себе – шлите текст, приближенный к реальности. «Хехей, у нас распродажа!». Даже если не будет распродажи, а пуш случайно уйдёт на всю базу – большая часть ничего и не заметит.
– Рисуете экран с информацией пользователя? Не придумывайте классные, идеальные данные – попросите настоящие из базы и изобразите их. Так и у разработчика будет меньше вопросов про «некрасивые» кейсы – они уже будут проиллюстрированы.
– Покрываете код юнит-тестами? Даже тут есть смысл использовать настоящие данные: если это имя – то должно быть имя, а не «A B» – это ещё один рубеж для отлова багов.
– Не хватает текста для какого-то экрана или письма? На время ожидания «настоящего» можно придумать его самому, вместо генерации lorem ipsum – мозг переключится на необычную для него задачу, это полезно. А если вдруг «настоящий» текст так никто и не напишет – это не будет блокером для быстрого релиза.
– Пишете какую-то инструкцию в слак/ноушен для коллег? Рассказываете про задачи соискателю? Рассказываете про продукт потенциальному клиенту? Используйте не стандартные, абстрактные примеры и кейсы, а реальные и близкие именно ему – он оценит.
Да, такой подход требует больше времени (совсем не много), но повышает качество.
Вам когда нибудь приходило пуш-уведомление от больших серьезных приложений с текстом «hey» или «test»? Мне за последние несколько лет раз 5 точно.
А всё потому, что кто-то при тестировании поленился подумать, а что же на самом деле будут слать пользователям? Чтобы не попадать в такие ситуации, есть простое правило – всегда использовать реальные данные. Оно работает для всех: продакты, дизайнеры, разработчики, QA... И дальше – продажники, маркетологи, контент-менеджеры и даже HR.
– Рассылаете тестовую email-рассылку или пуш? Даже если отправляете его только себе – шлите текст, приближенный к реальности. «Хехей, у нас распродажа!». Даже если не будет распродажи, а пуш случайно уйдёт на всю базу – большая часть ничего и не заметит.
– Рисуете экран с информацией пользователя? Не придумывайте классные, идеальные данные – попросите настоящие из базы и изобразите их. Так и у разработчика будет меньше вопросов про «некрасивые» кейсы – они уже будут проиллюстрированы.
– Покрываете код юнит-тестами? Даже тут есть смысл использовать настоящие данные: если это имя – то должно быть имя, а не «A B» – это ещё один рубеж для отлова багов.
– Не хватает текста для какого-то экрана или письма? На время ожидания «настоящего» можно придумать его самому, вместо генерации lorem ipsum – мозг переключится на необычную для него задачу, это полезно. А если вдруг «настоящий» текст так никто и не напишет – это не будет блокером для быстрого релиза.
– Пишете какую-то инструкцию в слак/ноушен для коллег? Рассказываете про задачи соискателю? Рассказываете про продукт потенциальному клиенту? Используйте не стандартные, абстрактные примеры и кейсы, а реальные и близкие именно ему – он оценит.
Да, такой подход требует больше времени (совсем не много), но повышает качество.
– Чтобы правильно сделать X нужно бесконечное количество времени. Поэтому следует делать X, в котором что-то не правильно.
– Создание X – итеративный процесс. Необходимое количество итераций всегда на одну больше, чем вы уже сделали.
– Ваши лучшие наработки в создании X окажутся бесполезными. Научитесь жить с разочарованием.
– Недостаток информации – не причина откладывать анализ решения.
– Не бывает одного правильного решения. Зато бывает много неправильных.
– Плохое решение с хорошей презентацией обречено в конечном итоге. Хорошее решение с плохой презентацией обречено сразу.
– Ты не можешь улучшить то, что ещё не работает.
– Всегда нет времени сделать хорошо, но чтобы потом переделывать – время всегда находится.
👆 Это законы Акина, а X – это космические системы. Ничего не напоминает?
P.S. их там 44, советую прочитать все.
P.P.S. Изначально я на них наткнулся у Самата – подписывайтесь на него
– Создание X – итеративный процесс. Необходимое количество итераций всегда на одну больше, чем вы уже сделали.
– Ваши лучшие наработки в создании X окажутся бесполезными. Научитесь жить с разочарованием.
– Недостаток информации – не причина откладывать анализ решения.
– Не бывает одного правильного решения. Зато бывает много неправильных.
– Плохое решение с хорошей презентацией обречено в конечном итоге. Хорошее решение с плохой презентацией обречено сразу.
– Ты не можешь улучшить то, что ещё не работает.
– Всегда нет времени сделать хорошо, но чтобы потом переделывать – время всегда находится.
👆 Это законы Акина, а X – это космические системы. Ничего не напоминает?
P.S. их там 44, советую прочитать все.
P.P.S. Изначально я на них наткнулся у Самата – подписывайтесь на него
Как правильно думать, чтобы выгорать?
В какой-то момент я начал замечать, что я думаю в моменты, когда закапываюсь в рутину и перестаю успевать важные дела, но постоянно чем-то занимаюсь. В итоге ощущаю стресс/тревогу/выгорание. Мой личный топ-5 и что я начал делать, чтобы этого избегать:
1. «Мне кто-то написал - нужно сразу ответить». Невозможно удерживать фокус, постоянно переключаясь в мессенджеры.
Решение: отключить уведомления и читать чаты раз в полчаса/час, вместо постоянного онлайна.
Результат: узнал, что много вопросов могут решиться без меня до того, как я успею ответить.
2. «Мне предлагают что-то обсудить. В календаре пусто, значит я не занят – тогда пойдём!». В какой-то момент для меня любая встреча, даже на 5 минут и вне зависимости от повестки стала важнее моих планов. Но ведь это не всегда так?
Решение: блокировать в календаре время под большие важные дела, а не только под встречи.
Результат: не стыдно отказать/перенести встречу на другое время, ведь ты занят и календарь это подтвержает.
3. «У меня много дел – нужно заниматься всем сразу, а то ничего не успею». В итоге всё равно ничего не успеваю, а отсуствие результатов демотивирует.
Решение: использовать принцип ohio – only hold it once и беря задачу доводить её до какой-то точки, выгружать из головы и радоваться результату.
Результат: больше задач доводятся до конца, а работается спокойнее.
4. «Меня попросили что-то сделать. Это займёт всего 10 минут – сделаю сразу». Когда я был разработчиком и меня просили оценить задачу – я называл срок и оооочень часто в него не укладывался. А теперь не укладываюсь в сроки, которые оцениваю для себя сам.
Решение: не верить себе и свою же оценку умножать на π (есть и чуть более сложные формулы – поищите свою).
Результат: если кажется, что задачу делать 10 минут, то я за нее не берусь сразу, т.к. велика вероятность, что она займёт 31.4. Другое дело задачки на 2 минуты!
5. «Вот всё доделаю – потом отдохну». 0 раз я доделал всё – всегда находится что-то ещё.
Решение: планировать и отдых тоже, а не только дела. Можно даже в календаре.
Результат: пока плохо получается 🙂
В каких мыслях заметили себя?
В какой-то момент я начал замечать, что я думаю в моменты, когда закапываюсь в рутину и перестаю успевать важные дела, но постоянно чем-то занимаюсь. В итоге ощущаю стресс/тревогу/выгорание. Мой личный топ-5 и что я начал делать, чтобы этого избегать:
1. «Мне кто-то написал - нужно сразу ответить». Невозможно удерживать фокус, постоянно переключаясь в мессенджеры.
Решение: отключить уведомления и читать чаты раз в полчаса/час, вместо постоянного онлайна.
Результат: узнал, что много вопросов могут решиться без меня до того, как я успею ответить.
2. «Мне предлагают что-то обсудить. В календаре пусто, значит я не занят – тогда пойдём!». В какой-то момент для меня любая встреча, даже на 5 минут и вне зависимости от повестки стала важнее моих планов. Но ведь это не всегда так?
Решение: блокировать в календаре время под большие важные дела, а не только под встречи.
Результат: не стыдно отказать/перенести встречу на другое время, ведь ты занят и календарь это подтвержает.
3. «У меня много дел – нужно заниматься всем сразу, а то ничего не успею». В итоге всё равно ничего не успеваю, а отсуствие результатов демотивирует.
Решение: использовать принцип ohio – only hold it once и беря задачу доводить её до какой-то точки, выгружать из головы и радоваться результату.
Результат: больше задач доводятся до конца, а работается спокойнее.
4. «Меня попросили что-то сделать. Это займёт всего 10 минут – сделаю сразу». Когда я был разработчиком и меня просили оценить задачу – я называл срок и оооочень часто в него не укладывался. А теперь не укладываюсь в сроки, которые оцениваю для себя сам.
Решение: не верить себе и свою же оценку умножать на π (есть и чуть более сложные формулы – поищите свою).
Результат: если кажется, что задачу делать 10 минут, то я за нее не берусь сразу, т.к. велика вероятность, что она займёт 31.4. Другое дело задачки на 2 минуты!
5. «Вот всё доделаю – потом отдохну». 0 раз я доделал всё – всегда находится что-то ещё.
Решение: планировать и отдых тоже, а не только дела. Можно даже в календаре.
Результат: пока плохо получается 🙂
В каких мыслях заметили себя?
А тем ли я занят? #toolset
Все знают про туду-листы и активно их используют. Чаще всего есть 3 состояния при работе со списком:
1. Что-то добавляем в него
2. Выбираем, чем заняться дальше
3. Чем-то занимаемся (как нам кажется – чем-то из этого списка)
С 3 пунктом у меня часто были проблемы. Очень легко увлечься, начать немного отходить в сторону от запланированной задачи и тут бам! Всё как в тумане – день закончился, я сделал много мелочей, а «главное дело» сделать не успел.
Как быть?
– Держать перед глазами «главное дело»
– Задавать себе вопрос «а тем ли я занят?..»
– Добавить осознанности. Если поймали себя на мысли, что заняты не тем – выбрать один из двух путей: либо добавить новое дело в верх списка и спокойно заниматься им, либо вернуться к «главному»
Из инструментов рекомендую (только для маководов):
– Если у вас есть тачбар – кастомизируйте его (вот мой). Например, по статье вастрика: я вывожу следующее событие из календаря и текущее «главное дело» из Things.
– Если нет – выводите в меню-бар. Например, с помощью effortless – его ещё можно использовать и для pomodoro-like техник
P.S. Пошучу шутку за вас: миллениалы придумали стикеры на монитор
Все знают про туду-листы и активно их используют. Чаще всего есть 3 состояния при работе со списком:
1. Что-то добавляем в него
2. Выбираем, чем заняться дальше
3. Чем-то занимаемся (как нам кажется – чем-то из этого списка)
С 3 пунктом у меня часто были проблемы. Очень легко увлечься, начать немного отходить в сторону от запланированной задачи и тут бам! Всё как в тумане – день закончился, я сделал много мелочей, а «главное дело» сделать не успел.
Как быть?
– Держать перед глазами «главное дело»
– Задавать себе вопрос «а тем ли я занят?..»
– Добавить осознанности. Если поймали себя на мысли, что заняты не тем – выбрать один из двух путей: либо добавить новое дело в верх списка и спокойно заниматься им, либо вернуться к «главному»
Из инструментов рекомендую (только для маководов):
– Если у вас есть тачбар – кастомизируйте его (вот мой). Например, по статье вастрика: я вывожу следующее событие из календаря и текущее «главное дело» из Things.
– Если нет – выводите в меню-бар. Например, с помощью effortless – его ещё можно использовать и для pomodoro-like техник
P.S. Пошучу шутку за вас: миллениалы придумали стикеры на монитор
Как получать качественный фидбек?
Я стараюсь регулярно немного изменять формат 1:1 митингов с сотрудниками. Недавно пробовал задавать вопросы в стиле 360 review о людях в команде:
– Что у него/неё получается хорошо?
– Что у него/неё получается не очень хорошо, но он этим занимается? (я специально не стал использовать слово «плохо»)
– Дай ему/ей любую рекомендацию, которая поможет вырасти профессионально
В конце просил сотрудника ответить на те же вопросы о себе, а потом – обо мне. Последние ответы были супер-полезными и я решил закинуть вопросы почти всем, с кем много работаю. И могу сказать, что это крутейший инструмент для получения адекватного фидбека. Какие выводы?
– Проще воспринимать негативный фидбек, когда ты сам попросил
– Люди охотнее делятся фидбеком, когда их об этом просят
– Некоторые всё-таки закрываются и отвечают в стиле «да всё ок!», «ты молодец!». Наверное, с такими людьми всё ещё нет нужного уровня доверия
– Люди дают фидбек не на эмоциях, когда «наболело». В обычном рациональном состоянии качество возрастает
– Многие включаются в игру и просят об ответной услуге, что запускает цепочку «адекватного» фидбека. Все в плюсе
– Задавая конкретные вопросы вероятность получить качественный ответ выше. На них проще ответить, чем на «дай мне какой-нибудь фидбек?»
В общем, хочешь получить полезный фидбек и найти свои зоны роста? Попроси о нём.
Я стараюсь регулярно немного изменять формат 1:1 митингов с сотрудниками. Недавно пробовал задавать вопросы в стиле 360 review о людях в команде:
– Что у него/неё получается хорошо?
– Что у него/неё получается не очень хорошо, но он этим занимается? (я специально не стал использовать слово «плохо»)
– Дай ему/ей любую рекомендацию, которая поможет вырасти профессионально
В конце просил сотрудника ответить на те же вопросы о себе, а потом – обо мне. Последние ответы были супер-полезными и я решил закинуть вопросы почти всем, с кем много работаю. И могу сказать, что это крутейший инструмент для получения адекватного фидбека. Какие выводы?
– Проще воспринимать негативный фидбек, когда ты сам попросил
– Люди охотнее делятся фидбеком, когда их об этом просят
– Некоторые всё-таки закрываются и отвечают в стиле «да всё ок!», «ты молодец!». Наверное, с такими людьми всё ещё нет нужного уровня доверия
– Люди дают фидбек не на эмоциях, когда «наболело». В обычном рациональном состоянии качество возрастает
– Многие включаются в игру и просят об ответной услуге, что запускает цепочку «адекватного» фидбека. Все в плюсе
– Задавая конкретные вопросы вероятность получить качественный ответ выше. На них проще ответить, чем на «дай мне какой-нибудь фидбек?»
В общем, хочешь получить полезный фидбек и найти свои зоны роста? Попроси о нём.
Правило сотни раз
Задумался: хороший результат не означает, что вы стали экспертом в вопросе. Например, можно создать успешное мобильное приложение. Но это не говорит, что вы научились делать успешные мобильные приложения. Если наняли хорошего сотрудника – это не значит, что вы научились их нанимать. Написали популярный пост – не значит, что научились их писать. Вообще про скилы есть известное правило 10000 часов.
Но у меня немного другое убеждение: решает не затраченное время, а количество разных подходов. Чтобы понять, как реально всё устроено и сформировать правильные нейронные связи, которые помогут вам интуитивно выбирать лучшие решения – нужно поучаствовать в создании 100 разных приложений, найме 100 человек, написании 100 постов. И желательно сделать их по-разному, использовать разные подходы.
Но на работе только один проект! Как больше пробовать?
– Чаще пробуйте
– Делайте сайд-проекты. Отличный инструмент, т.к. вы несете ответственность за результаты только перед самим собой (пока кто-то не начнёт ими пользоваться)
– Помогайте другим (людям, командам, компаниям). Разбирайтесь в их проблемах, помогайте искать решения. Возможно сначала вам даже не будут доверять, зато потом ещё и денег будут платить
– Изучайте чужой опыт. Его можно найти в книгах, статьях, конференциях и курсах
– Анализируйте чужие решения. Например, наш продакт Ира анализирует онбординги и пейволы мобильных приложений и выкладывает в канал
«Wisdom comes from experience. Experience is often a result of lack of wisdom» —Terry Pratchett
Задумался: хороший результат не означает, что вы стали экспертом в вопросе. Например, можно создать успешное мобильное приложение. Но это не говорит, что вы научились делать успешные мобильные приложения. Если наняли хорошего сотрудника – это не значит, что вы научились их нанимать. Написали популярный пост – не значит, что научились их писать. Вообще про скилы есть известное правило 10000 часов.
Но у меня немного другое убеждение: решает не затраченное время, а количество разных подходов. Чтобы понять, как реально всё устроено и сформировать правильные нейронные связи, которые помогут вам интуитивно выбирать лучшие решения – нужно поучаствовать в создании 100 разных приложений, найме 100 человек, написании 100 постов. И желательно сделать их по-разному, использовать разные подходы.
Но на работе только один проект! Как больше пробовать?
– Чаще пробуйте
– Делайте сайд-проекты. Отличный инструмент, т.к. вы несете ответственность за результаты только перед самим собой (пока кто-то не начнёт ими пользоваться)
– Помогайте другим (людям, командам, компаниям). Разбирайтесь в их проблемах, помогайте искать решения. Возможно сначала вам даже не будут доверять, зато потом ещё и денег будут платить
– Изучайте чужой опыт. Его можно найти в книгах, статьях, конференциях и курсах
– Анализируйте чужие решения. Например, наш продакт Ира анализирует онбординги и пейволы мобильных приложений и выкладывает в канал
«Wisdom comes from experience. Experience is often a result of lack of wisdom» —Terry Pratchett
Про собеседования
За 13 лет работы в IT я прошел десятки собеседований, из которых в 80% случаев я получал оффер, а из-за остальных ни разу не расстроился. Провел, думаю, уже больше пары сотен собеседований. И тут хочу поделиться своими идеями и мыслями про них:
– В большинстве компаний не нужны гении. Гениям, которые не хотят общаться с людьми, понимать ценность своей работы, аргументировать свои идеи и уважать людей вокруг больше подходит фриланс.
– На большинстве собеседований результат понятен в первые 5 минут. Дальше – самообман собеседующего, что он сможет что-то такое разглядеть, чтобы опровергнуть быстрое решение. Сам так делаю постоянно.
– Лучшее, что можно показать на собеседовании – что вам не всё равно то, чем, где и с кем вы занимаетесь. Именно люди, которым не всё равно двигают проекты, повышают качество, внедряют лучшие практики и процессы.
– Лучшие вопросы – те, которые не имеют правильного ответа. Рассуждения и ход мыслей важнее, чем конкретные знания. А конкретные знания можно получить у консультантов или тех же фрилансеров.
– Если при собеседовании в небольшую компанию для вас устраивают собеседование в стиле гугла – скорее всего в компании ещё сами не понимают, кто и зачем им нужен. Не забудьте это выяснить на таком собеседовании:)
За 13 лет работы в IT я прошел десятки собеседований, из которых в 80% случаев я получал оффер, а из-за остальных ни разу не расстроился. Провел, думаю, уже больше пары сотен собеседований. И тут хочу поделиться своими идеями и мыслями про них:
– В большинстве компаний не нужны гении. Гениям, которые не хотят общаться с людьми, понимать ценность своей работы, аргументировать свои идеи и уважать людей вокруг больше подходит фриланс.
– На большинстве собеседований результат понятен в первые 5 минут. Дальше – самообман собеседующего, что он сможет что-то такое разглядеть, чтобы опровергнуть быстрое решение. Сам так делаю постоянно.
– Лучшее, что можно показать на собеседовании – что вам не всё равно то, чем, где и с кем вы занимаетесь. Именно люди, которым не всё равно двигают проекты, повышают качество, внедряют лучшие практики и процессы.
– Лучшие вопросы – те, которые не имеют правильного ответа. Рассуждения и ход мыслей важнее, чем конкретные знания. А конкретные знания можно получить у консультантов или тех же фрилансеров.
– Если при собеседовании в небольшую компанию для вас устраивают собеседование в стиле гугла – скорее всего в компании ещё сами не понимают, кто и зачем им нужен. Не забудьте это выяснить на таком собеседовании:)
🧠 Про когнитивные искажения и быстрый фидбек
История 1. Некто Майкл Нортон провёл такой эксперимент: испытуемых попросили собрать самим мебель. После их спросили, какая мебель стоит дороже – собранная ими или абсолютно такая же, но собранная в ikea? В результате испытуемые были готовы платить больше за ту, которую собрали сами. Это когнитивное искажение так и называется – эффект ikea. Люди непропорционально высоко оценивают те вещи, в которые вложились сами.
История 2. Некто Макс Базерман устраивает для студентов MBA аукцион на 20$ купюру. Условия такие: её получает тот, кто сделает самую большую ставку. Но тот, кто окажется на втором месте будет обязан просто оплатить свою ставку, не получив ничего. Ближе к 20$ остаются 2 «победителя», которые перебивают ставки друг друга и в итоге купюра продаётся дороже своего номинала (рекорд – 204$). Это когнитивное искажение – боязнь потери. Людям важнее избежать потери 20$, чем получить эквивалентный доход.
История 3. Некто (подставьте сюда имя знакомого, ведь вы точно сталкивались с такой ситуацией или были её главным героем) получает большую задачу и идёт её выполнять. Он делает её очень долго, при этом старательно, вкладывает в неё много сил. Он никому не показывает промежуточный результат. И вот спустя месяц (или 2, 4, 6) всё готово. Это может быть огромный текст, сложный интерфейс, красивый дизайн, большое изменение в коде или целый стартап. Окружение начинает находить ошибки, предлагать улучшения, исправления и упрощения, но некто начинает яростно защищать своё творение. «Вы просто не понимаете!», «Вы не в контексте!», говорит он. И его можно понять – ведь он потратил столько времени, которое уже не вернуть. Он подвержен тем же когнитивным искажениям.
Какие выводы?
– Показывайте свою работу окружающим как можно раньше и остальных в команде просите делать так же. Чем меньше вы вложили в результат – тем объективнее вы воспримите фидбек.
– Собирайте фидбек с людей, не вовлеченных в разработку вашего продукта. Иначе получите фидбек, подверженный эффекту ikea
– Научитесь «откатывать» неудачные решения. Это сложно из-за иррационального усиления
История 1. Некто Майкл Нортон провёл такой эксперимент: испытуемых попросили собрать самим мебель. После их спросили, какая мебель стоит дороже – собранная ими или абсолютно такая же, но собранная в ikea? В результате испытуемые были готовы платить больше за ту, которую собрали сами. Это когнитивное искажение так и называется – эффект ikea. Люди непропорционально высоко оценивают те вещи, в которые вложились сами.
История 2. Некто Макс Базерман устраивает для студентов MBA аукцион на 20$ купюру. Условия такие: её получает тот, кто сделает самую большую ставку. Но тот, кто окажется на втором месте будет обязан просто оплатить свою ставку, не получив ничего. Ближе к 20$ остаются 2 «победителя», которые перебивают ставки друг друга и в итоге купюра продаётся дороже своего номинала (рекорд – 204$). Это когнитивное искажение – боязнь потери. Людям важнее избежать потери 20$, чем получить эквивалентный доход.
История 3. Некто (подставьте сюда имя знакомого, ведь вы точно сталкивались с такой ситуацией или были её главным героем) получает большую задачу и идёт её выполнять. Он делает её очень долго, при этом старательно, вкладывает в неё много сил. Он никому не показывает промежуточный результат. И вот спустя месяц (или 2, 4, 6) всё готово. Это может быть огромный текст, сложный интерфейс, красивый дизайн, большое изменение в коде или целый стартап. Окружение начинает находить ошибки, предлагать улучшения, исправления и упрощения, но некто начинает яростно защищать своё творение. «Вы просто не понимаете!», «Вы не в контексте!», говорит он. И его можно понять – ведь он потратил столько времени, которое уже не вернуть. Он подвержен тем же когнитивным искажениям.
Какие выводы?
– Показывайте свою работу окружающим как можно раньше и остальных в команде просите делать так же. Чем меньше вы вложили в результат – тем объективнее вы воспримите фидбек.
– Собирайте фидбек с людей, не вовлеченных в разработку вашего продукта. Иначе получите фидбек, подверженный эффекту ikea
– Научитесь «откатывать» неудачные решения. Это сложно из-за иррационального усиления
Интересно находить каналы, в которых обсуждаются схожие темы – понимаешь, что это не только твоя боль. Одна из таких находок – канал Кнопка Хорошо, в котором Анастасия Борисюк, руководитель проектов из «Актион Технологии» пишет идеально оформленные посты про софтскилы, процессы и общение с коллегами.
Сделал для вас подборку интересных постов:
– Почему так легко отвлечься на другую задачу?
– Плохие руководители
– Раздраженные люди. I часть. Что делать, когда на вас раздражаются?
– Большие письма. 1 часть о культуре переписки
– Синдром отложенной жизни
Сделал для вас подборку интересных постов:
– Почему так легко отвлечься на другую задачу?
– Плохие руководители
– Раздраженные люди. I часть. Что делать, когда на вас раздражаются?
– Большие письма. 1 часть о культуре переписки
– Синдром отложенной жизни
Как заниматься любимым делом?
Всем хочется получать удовольствие от работы. Самый простой способ – заниматься тем, чем хочется. Но часто в наших умах, воспитанных советскими родителями, есть установка: то, что нужно и важно – это не то, что хочется и от чего кайфуешь. Поэтому приходят люди, которые рассказывают нам, чем нужно заниматься, мы это делаем и лишь иногда это оказывается именно тем, что хочется. Делюсь формулой «любимых дел», которую я вывел для себя. В ней 3 слагаемых:
1. Инициативность
Тут всё банально: если вы не расскажете о ваших желаниях, идеях и предложениях – никто о них не узнает. И вероятность того, что вам прилетит задача именно с вашей идеей стремится к 0. Предлагайте и делайте. Но чтобы ваши инициативы чаще слышали и принимали – нужно добавить второй компонент.
2. Ценность для бизнеса
Помните про важность хорошей презентации? Чтобы сделать такую презентацию, нужно понимать, что важно тому, для кого она. А что может быть важнее для бизнеса, если не деньги? Понимать то, как работа превращается в деньги на счету компании – важный софт-скилл для любого сотрудника, в том числе для людей, которые не связаны напрямую с деньгами – разработчики, дизайнеры или, например, hr.
Этот скилл открывает возможность быстрее продавать свои инициативы ведь «нам надо всё переписать на go» звучит менее убедительно, чем «маркетинг говорит, что в конце квартала у нас ожидается в 10 раз больше клиентов. Если не перепишем вон ту часть, то придется платить в 10 раз больше за сервера». Но даже в такой формулировке менеджера, принимающего решение, может остановить последний компонент.
3. Ответственность
Да, есть люди, готовые брать на себя ответственность за чужие ошибки. Но в большинстве случаев проще брать в работу ваши инициативы, если вы сами сможете за них отвечать, особенно в случае неудачных решений (а никто от них не застрахован). Не будьте человеком из поста про я же говорил. Главное правило тут: ответственность не дают, её берут.
Итого: есть желание чем-то заняться? Предложите, обоснуйте ценность для бизнеса и возьмите ответственность за результат.
Всем хочется получать удовольствие от работы. Самый простой способ – заниматься тем, чем хочется. Но часто в наших умах, воспитанных советскими родителями, есть установка: то, что нужно и важно – это не то, что хочется и от чего кайфуешь. Поэтому приходят люди, которые рассказывают нам, чем нужно заниматься, мы это делаем и лишь иногда это оказывается именно тем, что хочется. Делюсь формулой «любимых дел», которую я вывел для себя. В ней 3 слагаемых:
1. Инициативность
Тут всё банально: если вы не расскажете о ваших желаниях, идеях и предложениях – никто о них не узнает. И вероятность того, что вам прилетит задача именно с вашей идеей стремится к 0. Предлагайте и делайте. Но чтобы ваши инициативы чаще слышали и принимали – нужно добавить второй компонент.
2. Ценность для бизнеса
Помните про важность хорошей презентации? Чтобы сделать такую презентацию, нужно понимать, что важно тому, для кого она. А что может быть важнее для бизнеса, если не деньги? Понимать то, как работа превращается в деньги на счету компании – важный софт-скилл для любого сотрудника, в том числе для людей, которые не связаны напрямую с деньгами – разработчики, дизайнеры или, например, hr.
Этот скилл открывает возможность быстрее продавать свои инициативы ведь «нам надо всё переписать на go» звучит менее убедительно, чем «маркетинг говорит, что в конце квартала у нас ожидается в 10 раз больше клиентов. Если не перепишем вон ту часть, то придется платить в 10 раз больше за сервера». Но даже в такой формулировке менеджера, принимающего решение, может остановить последний компонент.
3. Ответственность
Да, есть люди, готовые брать на себя ответственность за чужие ошибки. Но в большинстве случаев проще брать в работу ваши инициативы, если вы сами сможете за них отвечать, особенно в случае неудачных решений (а никто от них не застрахован). Не будьте человеком из поста про я же говорил. Главное правило тут: ответственность не дают, её берут.
Итого: есть желание чем-то заняться? Предложите, обоснуйте ценность для бизнеса и возьмите ответственность за результат.