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