Про слак, часть 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. Ответственность
Да, есть люди, готовые брать на себя ответственность за чужие ошибки. Но в большинстве случаев проще брать в работу ваши инициативы, если вы сами сможете за них отвечать, особенно в случае неудачных решений (а никто от них не застрахован). Не будьте человеком из поста про я же говорил. Главное правило тут: ответственность не дают, её берут.
Итого: есть желание чем-то заняться? Предложите, обоснуйте ценность для бизнеса и возьмите ответственность за результат.
👍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 сотрудника закидывают в компанию и ничего не требуют (но потом могут уволить, если не будет результатов). Джобс…