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 доказано положительно влияет на долгосрочные бизнес метрики.
Отсюда следует, что не стоит соглашаться писать фидбэк всем подряд, а кому соглашаетесь, не комментируйте весь документ, а только конкретные места. Спросите себя -- можете ли вы быть артефактом для этого заявления? Есть ли у вас признание вашей экспертности в необходимом автору домене, или будет ли ваш комментарий проигнорирован? Пишите фидбэк только о том, где у вас есть признанный организацией авторитет.
Автор фидбэка, запомни: ты -- артефакт.
Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.
Forwarded from Тоже Паша Техник
RL база.pdf
451.4 KB
живой 🫡
учеба, работа, не совсем успеваю писать
👀 ловите мой "нихуя-как-просто" инсайт с курса по RL у нас в маге.
Без всяких формул и мудрёных греческих букв расскажу, как работает обучение с подкреплением и почему именно оно заставляет большую языковую модель не тупо бубнить текст из интернета, а вести себя так, как нужно нам — слушать промпт, ловко фильтровать бред, фокусироваться на сути и выдавать ответы, за которые реально не стыдно.
Попытался написать максимально просто, но насколько далеко вы прочитаете, зависит от вашего опыта в ML
учеба, работа, не совсем успеваю писать
Без всяких формул и мудрёных греческих букв расскажу, как работает обучение с подкреплением и почему именно оно заставляет большую языковую модель не тупо бубнить текст из интернета, а вести себя так, как нужно нам — слушать промпт, ловко фильтровать бред, фокусироваться на сути и выдавать ответы, за которые реально не стыдно.
Попытался написать максимально просто, но насколько далеко вы прочитаете, зависит от вашего опыта в ML
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тоже Паша Техник
model are only as good as the context provided to them
- компьютер — это агент
- мышка, клавиатура, микрофон — это инструменты и различные источники контекста для LLM
- usb-c хаб — как раз model context protocol
по сути мы действительно "вставляем" все нужные нам инструменты и источники в парадигму MCP и затем просто используем этот протокол как стандартизированный способ общения с "контекстом".
MCP стандартизирует, как AI приложения взаимодействуют с внешними системами – аналогично тому, как API задают правила общения между веб-приложениями и backend.
Протокол охватывает промпты, тулзы и ресурсы.
У нас есть агент, у которого есть инструменты:
- сходить в задачник (jira) по API и вернуть нужную таску конкретного юзера
- сходить в github и сделать PR в репозитории
Агент с первой картинки:
1. на вход юзер подает тикет
2. агент запрашивает таску
3. решает задачку
4. создает pull request на сделанную задачу
также у нас есть еще пара агентов, которые так или иначе используют API jira и github.
- что если API изменилось? — тогда в каждом агенте придется делать правки
- что если вы захотели изменить пайплайн в каком-то агенте, так как API теперь позволяет еще и прикреплять ревьюера к PR? — придется добавить в агента новый интструмент.
а теперь представим, что у нас есть отдельные сервера для jira и github, в которых прописаны какие инструменты есть и как их использовать. Эти сервера имеют стандартизированные ручки, параметры и ответы.
теперь мы берем агента, говорим зачем он создан и даем ему доступ к этим серверам. При инициализации агент сам спросит у серверов, какие у них есть возможности и будет учитывать их при выполнении запросов. (агент на второй картинке)
этими серверами могут делиться другие разработчики, которые уже написали, например, сервер для взаимодействия с figma.
Архитектура MCP базируется на клиент-серверной модели:
- Host Process – основное AI-приложение (например, Claude Desktop или Cursor)
- MCP Clients – клиенты, которые устанавливают отдельное соединение с каждым сервером
- MCP Servers – специализированные серверы, предоставляющие инструменты и доступ к данным
плюсы: упрощает покдлючение и поддержку новых источников для контекста
минусы: первоначальная настройка и подготовка своей инфры под этот протокол, валидация возможностей чужих серверов + написание своих
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM