Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Деньги мотивируют или демотивируют? Финансовая мотивация сотрудников глазами IT-менеджера
Сегодня вам принес видос про деньги-денежки-деньжищи https://www.youtube.com/watch?v=Stpa2FfCP8c
Мне в нем понравился разбор разных исследований, теории справедливости и как вообще деньги влияют на удовлетворенность от работы. Особенно интересно смотрится эксперимент с капуцинами и история про абсолютные и относительные деньги. Например, удовлетворен человек своей зарплатой и всё ему хорошо. Но стоит ему узнать, что соседу платят за примерно (он не знает точно) то же самое на 5% больше, как уже просыпается праведный гнев и сильная дизмораль 🙂
Я по-прежнему продолжаю напоминать, что как бы я ни искал в банковском приложении, всё еще не могу найти, как ипотеку оплатить интересными задачами или дружным коллективом. Тем не менее точно не только на деньгах свет клином сошелся.
Короче, смотрите, составляйте свое мнение, делитесь им в комментариях.
Спасибо Вите Корейше, что мне это видео скинул. Похоже, нового альтернативного человека не из нашего пузыря открыл мне, которого можно посматривать. Самобытный такой персонаж, судя по всему. Люблю такое 🙂
Сегодня вам принес видос про деньги-денежки-деньжищи https://www.youtube.com/watch?v=Stpa2FfCP8c
Мне в нем понравился разбор разных исследований, теории справедливости и как вообще деньги влияют на удовлетворенность от работы. Особенно интересно смотрится эксперимент с капуцинами и история про абсолютные и относительные деньги. Например, удовлетворен человек своей зарплатой и всё ему хорошо. Но стоит ему узнать, что соседу платят за примерно (он не знает точно) то же самое на 5% больше, как уже просыпается праведный гнев и сильная дизмораль 🙂
Я по-прежнему продолжаю напоминать, что как бы я ни искал в банковском приложении, всё еще не могу найти, как ипотеку оплатить интересными задачами или дружным коллективом. Тем не менее точно не только на деньгах свет клином сошелся.
Короче, смотрите, составляйте свое мнение, делитесь им в комментариях.
Спасибо Вите Корейше, что мне это видео скинул. Похоже, нового альтернативного человека не из нашего пузыря открыл мне, которого можно посматривать. Самобытный такой персонаж, судя по всему. Люблю такое 🙂
Forwarded from Вероника отвечает (Veronika Ilina)
💎 В MIT 40 лет читают лекцию о том, как читать лекции выступать. И она уже несколько лет доступна на Ютубе.
Там всё: как доносить мысль, как структурировать, что делать и не делать со слайдами. Естественно, те же рекомендованные принципы используются в самом мета-докладе.
Даже опытные спикеры могут что-то новое для себя найти, или старое вспомнить, и заиспользовать на основе этой лекции.
Я, например, крепко задумалась про использование реквизита на оффлайн-выступлениях. Патрик во время лекции использует указку, чтобы донести одну идею, и делает это так, что идею зритель точно запоминает. 🙂
Видео здесь, а ниже — цитата из лекции.
Там всё: как доносить мысль, как структурировать, что делать и не делать со слайдами. Естественно, те же рекомендованные принципы используются в самом мета-докладе.
Даже опытные спикеры могут что-то новое для себя найти, или старое вспомнить, и заиспользовать на основе этой лекции.
Я, например, крепко задумалась про использование реквизита на оффлайн-выступлениях. Патрик во время лекции использует указку, чтобы донести одну идею, и делает это так, что идею зритель точно запоминает. 🙂
Видео здесь, а ниже — цитата из лекции.
“Your success in life will be determined largely by your ability to speak, your ability to write, and the quality of your ideas. In that order." — Patrick Winston
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Продолжаю учиться на курсе Школа технического директора от Стратоплана
Продолжаю писать про материалы с курса посвященными процессам. Сегодня распишу своими словами как я понял материал по теме: Строгие и гибкие процессы.
🔵 Введение
Строгие процессы — это чётко прописанные правила и инструкции, которым сотрудники обязаны следовать. Например, выполнение всех шагов в определённой последовательности и соблюдение стандартов качества. Такие процессы помогают избежать ошибок и обеспечить стабильность работы.
Гибкие процессы — это менее жёсткая система правил, позволяющая сотрудникам действовать свободно и адаптироваться к новым условиям. Главное внимание уделяется результатам, а не выполнению заранее установленных процедур. Это помогает быстрее реагировать на изменения и внедрять новые идеи.
Первая мысль которая мне откликнулась в рассказе тренера - строгость или гибкость это очень условные и растяжимые понятия. Чаще всего в реальной жизни процессы это некоторый спектр. По опыту тренера и моему личному - любые крайности это скорее ограничение чем возможность. Тренер также отметил что даже в ГОСТах и различных ISO документах по процессам, которые на первый взгляд должны быть супер строгими и формальными встречаются сноски позволяющие видоизменять и адаптировать процесс под свою ситуацию.
Поэтому имеет смысл попробовать взглянуть на свои процессы через призму и оценить в каких этапах присутствует строгость, а в каких гибкость.
🔵 Как выбрать?
Но если мы только строим процессы - на что нам стоит опереться как базис? На первый взгляд может показаться, что конечно нужно брать гибкие процессы, так как это модно-молодежно. Но такое целеполагание может привести к проблемам (вспоминаем продукты и проекты из прошлого поста). Важно учитывать многие факторы, рассмотрю несколько:
Степень риска - в случае если цена ошибки высока строгий процесс будет предпочтительным чем гибкий.
Динамичность рынка - если мы работаем в высококонкурентной среде где побеждает тот кто зарелизил быстрее, гибкие процессы помогут не застревать на бюрократии и согласованиях. В гибких процессах мы в первую очередь фокусируемся на результате, если есть что-то мешающее его достичь - нафиг.
Квалификация исполнителей - когда у нас есть опытные профи способные сами определить как достичь цели. Для новичков без опыта или с маленьким опытом - наличие инструкций и пошаговых руководств обязательно.
Уникальность / Регулярность задач - если мы делаем нечто инновационное или около того строгие процессы не позволят проявить креативность и творческую жилку. В свою очередь если у нас понятные задачи day by day то гибкость процессов будет скорее вредна, так как доставка ценности может увеличиться из за того что ребята будут делать так как им удобно а не оптимально.
Как найти баланс?
Отмечу главный пункт по моему мнению и который также упомянул тренер - Насаждение культуры инноваций и нетерпеливости к неудобствам. Атмосфера и зрелость сотрудников в отделе или команде должна быть такой чтобы можно было честно и открыто делиться обратной связью, подмечать шероховатости в процессах, предлагать улучшения и брать ответственность за внедрение. Сотрудники должны быть по хорошему жадными и ценить свое время, проактивно приносить руководителю обратную связь по результатам работы.
🔵 Лидерство.
В разных процессах и фокус руководителя будет на разных вещах. Короткое саммари от тренера:
Роль лидера в строгих процессах
- Контроль качества и производительности
- Контроль дисциплины и следования нормативной документации
- Управление рисками
- Корректировка процессов и работа с аномалиями
Роль лидера в гибких процессах
- Создание благоприятной среды для автономности и гибкости
- Контроль дисциплины и следования принятым практикам
- Устранение препятствий для роста и развития
- Культивирование самостоятельности и инициативности
Как видите, отличия сильные, не перепутайте😇
----
На этом всё, пост получился очень большим, при этом я не рассказал и 10% того что было на курсе, так что если у вас появились вопросы после прочтения - пишите в комментарии, поразгоняем обсуждение😊
Продолжаю писать про материалы с курса посвященными процессам. Сегодня распишу своими словами как я понял материал по теме: Строгие и гибкие процессы.
🔵 Введение
Строгие процессы — это чётко прописанные правила и инструкции, которым сотрудники обязаны следовать. Например, выполнение всех шагов в определённой последовательности и соблюдение стандартов качества. Такие процессы помогают избежать ошибок и обеспечить стабильность работы.
Гибкие процессы — это менее жёсткая система правил, позволяющая сотрудникам действовать свободно и адаптироваться к новым условиям. Главное внимание уделяется результатам, а не выполнению заранее установленных процедур. Это помогает быстрее реагировать на изменения и внедрять новые идеи.
Первая мысль которая мне откликнулась в рассказе тренера - строгость или гибкость это очень условные и растяжимые понятия. Чаще всего в реальной жизни процессы это некоторый спектр. По опыту тренера и моему личному - любые крайности это скорее ограничение чем возможность. Тренер также отметил что даже в ГОСТах и различных ISO документах по процессам, которые на первый взгляд должны быть супер строгими и формальными встречаются сноски позволяющие видоизменять и адаптировать процесс под свою ситуацию.
Поэтому имеет смысл попробовать взглянуть на свои процессы через призму и оценить в каких этапах присутствует строгость, а в каких гибкость.
🔵 Как выбрать?
Но если мы только строим процессы - на что нам стоит опереться как базис? На первый взгляд может показаться, что конечно нужно брать гибкие процессы, так как это модно-молодежно. Но такое целеполагание может привести к проблемам (вспоминаем продукты и проекты из прошлого поста). Важно учитывать многие факторы, рассмотрю несколько:
Степень риска - в случае если цена ошибки высока строгий процесс будет предпочтительным чем гибкий.
Динамичность рынка - если мы работаем в высококонкурентной среде где побеждает тот кто зарелизил быстрее, гибкие процессы помогут не застревать на бюрократии и согласованиях. В гибких процессах мы в первую очередь фокусируемся на результате, если есть что-то мешающее его достичь - нафиг.
Квалификация исполнителей - когда у нас есть опытные профи способные сами определить как достичь цели. Для новичков без опыта или с маленьким опытом - наличие инструкций и пошаговых руководств обязательно.
Уникальность / Регулярность задач - если мы делаем нечто инновационное или около того строгие процессы не позволят проявить креативность и творческую жилку. В свою очередь если у нас понятные задачи day by day то гибкость процессов будет скорее вредна, так как доставка ценности может увеличиться из за того что ребята будут делать так как им удобно а не оптимально.
Как найти баланс?
Отмечу главный пункт по моему мнению и который также упомянул тренер - Насаждение культуры инноваций и нетерпеливости к неудобствам. Атмосфера и зрелость сотрудников в отделе или команде должна быть такой чтобы можно было честно и открыто делиться обратной связью, подмечать шероховатости в процессах, предлагать улучшения и брать ответственность за внедрение. Сотрудники должны быть по хорошему жадными и ценить свое время, проактивно приносить руководителю обратную связь по результатам работы.
🔵 Лидерство.
В разных процессах и фокус руководителя будет на разных вещах. Короткое саммари от тренера:
Роль лидера в строгих процессах
- Контроль качества и производительности
- Контроль дисциплины и следования нормативной документации
- Управление рисками
- Корректировка процессов и работа с аномалиями
Роль лидера в гибких процессах
- Создание благоприятной среды для автономности и гибкости
- Контроль дисциплины и следования принятым практикам
- Устранение препятствий для роста и развития
- Культивирование самостоятельности и инициативности
Как видите, отличия сильные, не перепутайте😇
----
На этом всё, пост получился очень большим, при этом я не рассказал и 10% того что было на курсе, так что если у вас появились вопросы после прочтения - пишите в комментарии, поразгоняем обсуждение😊
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Решил сделать перерыв от высоких менеджерских материй и запостить простой годноты, которую встречаю в day by day работе.
Сегодняшний лот - статья с подробнейшим разбором такого понятия как CPU Throttling.
Под катом:
- Что такое CPU Throttling, какое влияние оказывает на сервис под нагрузкой?
- Как в K8s работают CPU limits?
- Как можно столкнуться с CPU Throttling на примере Golang?
- K8s limits, requests + GOMAXPROCS
- Milliseconds vs Cores, что будет если установить программе в K8s лимиты < 1?
Очень советую к прочтению, если не сталкивались, это важная и полезная база. И, конечно, проверьте дашборды сервисов на наличие панелек с индикаторами троттлинга, нужная штука при разборе инцидентов.
https://kanishk.io/posts/cpu-throttling-in-containerized-go-apps/
-----
Делитесь в комментариях своим опытом связанным с CPU нагрузками, где и чего оптимизировали, как избавлялись от троттлинга сервисов?😊
Сегодняшний лот - статья с подробнейшим разбором такого понятия как CPU Throttling.
Под катом:
- Что такое CPU Throttling, какое влияние оказывает на сервис под нагрузкой?
- Как в K8s работают CPU limits?
- Как можно столкнуться с CPU Throttling на примере Golang?
- K8s limits, requests + GOMAXPROCS
- Milliseconds vs Cores, что будет если установить программе в K8s лимиты < 1?
Очень советую к прочтению, если не сталкивались, это важная и полезная база. И, конечно, проверьте дашборды сервисов на наличие панелек с индикаторами троттлинга, нужная штука при разборе инцидентов.
https://kanishk.io/posts/cpu-throttling-in-containerized-go-apps/
-----
Делитесь в комментариях своим опытом связанным с CPU нагрузками, где и чего оптимизировали, как избавлялись от троттлинга сервисов?😊
Forwarded from прод не упал
Как понять, кто ты по Адизесу
В первой части поста мы разбирали управленческие роли по Адизесу: Производитель, Администратор, Предприниматель и Интегратор. Теперь расскажем, как определить, кто вы или ваши коллеги в этой системе.
Самый точный способ — это официальный тест от Adizes Institute. Его разработала команда самого Адизеса. Он содержит 60 вопросов о ваших поведенческих предпочтениях в работе. Пройти тест можно бесплатно на сайте института — adizes.com, нужно будет только заполнить анкету с контактными данными. Лучше проходить его на английском языке, потому что перевод на русский там так себе.
Кроме официального теста есть еще аналоги, в том числе на русском языке — все они легко гуглятся по запросу "paei тест". Их много, но суть везде одинаковая.
И наверно самый лучший из всех, третий, способ — наблюдать за собой и коллегами. Адизес описывает не "типы личности", а поведенческие роли. И их можно и нужно замечать в жизни.
Например, если вас драйвят результаты и вы свято чтите дедлайны — скорее всего, вы Производитель. Если вам интереснее работать с регламентами, наводить порядок и налаживать процессы, то вы ближе к Администратору. Если вы вечно фонтанируете идеями, предлагаете изменения и подбиваете команду на эксперименты, вы Предприниматель. Любите объединять, слушать и собирать? Поздравляем, вы Интегратор.
В этой связи хорошо работает открытое обсуждение в команде: кратко расскажите коллегам про PAEI, а потом делитесь, кто кем себя (и другого) ощущает. В неформальной обстановке такие разговоры дают много ценной информации, особенно если в команде всё по-честному.
А теперь можно поделиться в комментариях, кем вы себя ощущаете. Только помните, что 1) плохих ролей не бывает; 2) у человека могут быть две ярко-выраженные роли, но не больше.
В первой части поста мы разбирали управленческие роли по Адизесу: Производитель, Администратор, Предприниматель и Интегратор. Теперь расскажем, как определить, кто вы или ваши коллеги в этой системе.
Самый точный способ — это официальный тест от Adizes Institute. Его разработала команда самого Адизеса. Он содержит 60 вопросов о ваших поведенческих предпочтениях в работе. Пройти тест можно бесплатно на сайте института — adizes.com, нужно будет только заполнить анкету с контактными данными. Лучше проходить его на английском языке, потому что перевод на русский там так себе.
Кроме официального теста есть еще аналоги, в том числе на русском языке — все они легко гуглятся по запросу "paei тест". Их много, но суть везде одинаковая.
И наверно самый лучший из всех, третий, способ — наблюдать за собой и коллегами. Адизес описывает не "типы личности", а поведенческие роли. И их можно и нужно замечать в жизни.
Например, если вас драйвят результаты и вы свято чтите дедлайны — скорее всего, вы Производитель. Если вам интереснее работать с регламентами, наводить порядок и налаживать процессы, то вы ближе к Администратору. Если вы вечно фонтанируете идеями, предлагаете изменения и подбиваете команду на эксперименты, вы Предприниматель. Любите объединять, слушать и собирать? Поздравляем, вы Интегратор.
В этой связи хорошо работает открытое обсуждение в команде: кратко расскажите коллегам про PAEI, а потом делитесь, кто кем себя (и другого) ощущает. В неформальной обстановке такие разговоры дают много ценной информации, особенно если в команде всё по-честному.
А теперь можно поделиться в комментариях, кем вы себя ощущаете. Только помните, что 1) плохих ролей не бывает; 2) у человека могут быть две ярко-выраженные роли, но не больше.
Forwarded from прод не упал
Hindsight bias: знание задним числом
Продолжаем говорить о когнитивных ловушках. Сегодня - один из самых коварных сбоев мышления: знание задним числом, оно же hindsight bias.
Это тот самый эффект, когда всё становится "очевидным" только после того, как произошло и хочется сказать что-то вроде: "Да я с самого начала знал, что так и будет, и ежу было понятно".
Прикол тут в том, что на самом деле вы не знали. Но наш мозг не любит неопределённость и с удовольствием подменяет память удобной ему интерпретацией.
В результате мы начинаем верить, что всё предсказали заранее, и, как следствие, не учимся на приобретенном опыте. Не анализируем ошибки, не улучшаем прогнозы, не развиваем системное мышление, потому что "ну и так же все понятно".
Вот пара примеров:
- У вас по каким-то причинам провалился релиз, после чего продакт начинает говорить, что все изначально шло не так. При этом он ничего не предпринял, а за два дня до дедлайна писал, что все окей.
- Отвалился крупный клиент, команда собирается на обсуждение и приходит к выводу, что все сделали правильно, это клиент какой-то мутный оказался. И вообще с самого начала было ощущение, что с ним не сработаемся. А в CRM при этом написано, что у клиента высокий интерес, теплый контакт и вообще все прекрасно.
Как не попасть в ловушку знания задним числом?
1. Фиксируйте гипотезы и ожидания заранее. Перед важным решением коротко запишите, что вы ожидаете. Так вы дадите себе шанс провести анализ, основанный на фактах, а не ощущениях.
2. Не верьте памяти, верьте бумаге. Перепроверяйте старые документы, заметки и письма - они точнее расскажут, что вы на самом деле думали. Воспоминания постоянно меняются, но то, что вы написали навсегда останется в неизменном виде.
3. Оставляйте место для неожиданностей. Если случившееся событие кажется предсказуемым, попробуйте честно спросить себя: а сколько ещё вариантов могло быть? Почему тогда вы не выбрали их?
Hindsight bias - это такой тихий и незаметный враг, напоминающий паразита. Он не шумит, не делает больно и не лишает сна. Он подменяет реальность и тем самым блокирует возможность увидеть зону роста и стать сильнее.
Так что в следующий раз, когда на ум придет "да и так все было понятно", задумайтесь, не попались ли вы в ловушку собственного мышления.
Продолжаем говорить о когнитивных ловушках. Сегодня - один из самых коварных сбоев мышления: знание задним числом, оно же hindsight bias.
Это тот самый эффект, когда всё становится "очевидным" только после того, как произошло и хочется сказать что-то вроде: "Да я с самого начала знал, что так и будет, и ежу было понятно".
Прикол тут в том, что на самом деле вы не знали. Но наш мозг не любит неопределённость и с удовольствием подменяет память удобной ему интерпретацией.
В результате мы начинаем верить, что всё предсказали заранее, и, как следствие, не учимся на приобретенном опыте. Не анализируем ошибки, не улучшаем прогнозы, не развиваем системное мышление, потому что "ну и так же все понятно".
Вот пара примеров:
- У вас по каким-то причинам провалился релиз, после чего продакт начинает говорить, что все изначально шло не так. При этом он ничего не предпринял, а за два дня до дедлайна писал, что все окей.
- Отвалился крупный клиент, команда собирается на обсуждение и приходит к выводу, что все сделали правильно, это клиент какой-то мутный оказался. И вообще с самого начала было ощущение, что с ним не сработаемся. А в CRM при этом написано, что у клиента высокий интерес, теплый контакт и вообще все прекрасно.
Как не попасть в ловушку знания задним числом?
1. Фиксируйте гипотезы и ожидания заранее. Перед важным решением коротко запишите, что вы ожидаете. Так вы дадите себе шанс провести анализ, основанный на фактах, а не ощущениях.
2. Не верьте памяти, верьте бумаге. Перепроверяйте старые документы, заметки и письма - они точнее расскажут, что вы на самом деле думали. Воспоминания постоянно меняются, но то, что вы написали навсегда останется в неизменном виде.
3. Оставляйте место для неожиданностей. Если случившееся событие кажется предсказуемым, попробуйте честно спросить себя: а сколько ещё вариантов могло быть? Почему тогда вы не выбрали их?
Hindsight bias - это такой тихий и незаметный враг, напоминающий паразита. Он не шумит, не делает больно и не лишает сна. Он подменяет реальность и тем самым блокирует возможность увидеть зону роста и стать сильнее.
Так что в следующий раз, когда на ум придет "да и так все было понятно", задумайтесь, не попались ли вы в ловушку собственного мышления.
Forwarded from ИИгорь R&D
Очень толковая статья попалась на хабре. Короткая и по делу вся
Как собрать Docker-образ, который можно запускать в проде (а не только у себя на ноуте) https://habr.com/p/917226/
Как собрать Docker-образ, который можно запускать в проде (а не только у себя на ноуте) https://habr.com/p/917226/
Habr
Как собрать Docker-образ, который можно запускать в проде (а не только у себя на ноуте)
Если ты пишешь Dockerfile , скорее всего, он работает. Но вопрос не в том, работает ли. Вопрос в другом: будет ли он работать через неделю, на другом сервере, в CI/CD, на чужом железе — и будет ли это...
Forwarded from Korenev AI - GPT в тапочках🩴
Покрутил в руках dify.ai
Это некий аналог n8n, конструктор, который быстро позволяет создать ИИ сервис с собственной базой знаний.
Сервис, кстати, опенсорсный, можно у себя на локалке развернуть. 103к звезд на гитхабе - столько же сколько у n8n, т.е. эти 2 проекта равнообожаемы
В сервисе реализован гибридный поиск: векторный (семантический) + полнотекстовый
При этом релевантные чанки можно выбирать или по весу, или подключая реранкер cohere
Но не хватает мне в этом сервисе предварительной обработки загружаемых документов. Хотелось бы разметить структуру, сделать саммари разделов - в общем сделать маппинг документа, который потом можно использовать в промпте.
Потестил chunkr.ai - там много разных стратегий обработки документа, включая OCR, но сервис работает только с англоязычными доками, как я понял, во всяком случае мою пдфку на английском разобрал. Ну и по сути это не совсем то, что хотелось бы
Вопрос в зал:
Есть ли опенсорсные решения, которые позволяют делать такой маппинг?
Вопрос2:
Кто в своих проектах успешно использует GraphRag? На каком стеке?
Это некий аналог n8n, конструктор, который быстро позволяет создать ИИ сервис с собственной базой знаний.
Сервис, кстати, опенсорсный, можно у себя на локалке развернуть. 103к звезд на гитхабе - столько же сколько у n8n, т.е. эти 2 проекта равнообожаемы
В сервисе реализован гибридный поиск: векторный (семантический) + полнотекстовый
При этом релевантные чанки можно выбирать или по весу, или подключая реранкер cohere
Но не хватает мне в этом сервисе предварительной обработки загружаемых документов. Хотелось бы разметить структуру, сделать саммари разделов - в общем сделать маппинг документа, который потом можно использовать в промпте.
Потестил chunkr.ai - там много разных стратегий обработки документа, включая OCR, но сервис работает только с англоязычными доками, как я понял, во всяком случае мою пдфку на английском разобрал. Ну и по сути это не совсем то, что хотелось бы
Вопрос в зал:
Есть ли опенсорсные решения, которые позволяют делать такой маппинг?
Вопрос2:
Кто в своих проектах успешно использует GraphRag? На каком стеке?
Forwarded from Korenev AI - GPT в тапочках🩴
Вчера консультировал команду, которая занимается речевой аналитикой. Ребята столкнулись с типичной проблемой: на малых объемах данных все работает нормально, но при увеличении ллм начинает некорректно работать
Слишком большой промпт с кучей подробностей, инструкций и множеством сущностей для классификации. Нужно было много элементов разложить по кучкам, но кучек слишком много, и ллм просто не справляется с такой нагрузкой.
Решение простое: разбить промпт на несколько, чтобы каждый из них выполнял лишь одну конкретную задачу. По моим оценкам этот промпт надо на разбить на 3-5 шагов.
Главное - опытным путем найти оптимальное количество данных, которое конкретная модель может нормально обработать.
Интересно ваше мнение - что еще посоветовали бы начинающим разработчикам?
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Карьера в FAANG
Я рассказал, как писать половину performance review -- self assessment документ. В этом, завершающем цикл, посте поговорим о том, как писать вторую половину -- peer feedback.
Ваши коллеги тоже пишут свой performance review, после чего просят вас написать им фидбэк. Вам нужно будет прокомментировать их работу. Но не просто прокомментировать, а так, чтобы ваши комментарии были полезны оценивающему людей комитету. Эту часть нельзя забывать. Так же, как и в вашем собственном документе, в фидбеке неуместны произвольные возгласы похвалы или критики.
Прежде, чем советовать, что делать, посоветую, чего не делать: не нужно помогать коллеге дописать его self assessment своим фидбэком. Не нужно писать -- ах вот тут еще забыл такую-то деталь! Если приходят такие мысли, передайте их автору приватно. Во-вторых, не стоит комментировать человека. Вы даете фидбэк не человеку, а документу. Человеку можно дать фидбэк лично, или его менеджеру, если есть желание. Ваша работа -- строго прокомментировать существующий контент документа.
В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.
Ваши коллеги тоже пишут свой performance review, после чего просят вас написать им фидбэк. Вам нужно будет прокомментировать их работу. Но не просто прокомментировать, а так, чтобы ваши комментарии были полезны оценивающему людей комитету. Эту часть нельзя забывать. Так же, как и в вашем собственном документе, в фидбеке неуместны произвольные возгласы похвалы или критики.
Прежде, чем советовать, что делать, посоветую, чего не делать: не нужно помогать коллеге дописать его self assessment своим фидбэком. Не нужно писать -- ах вот тут еще забыл такую-то деталь! Если приходят такие мысли, передайте их автору приватно. Во-вторых, не стоит комментировать человека. Вы даете фидбэк не человеку, а документу. Человеку можно дать фидбэк лично, или его менеджеру, если есть желание. Ваша работа -- строго прокомментировать существующий контент документа.
В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.