Пока Anthropic Claude 4 Sonnet лучше для ежедневных задач разработчиков
Вот так выглядит ТОП-10 моделей в статистике за неделю на сайте OpenRouter https://vk.cc/cOiVWB
Можно заметить, что если сложить все модели от Google, то они суммарно занимают первое место. Но в этих рассуждениях есть одно «но». Модели Gemini 2.0 и 2.5 Flash — это очень быстрые и дешевые модели, которые, как правило, используют не для разработки, а для небольших задач. А вот Gemini 2.5 Pro — это прямой конкурент для Anthropic Claude 4 Sonnet, и здесь отчетливо видно, что у Anthropic 4-кратное преимущество перед Google за счет качества модели у разработчиков. Это говорит о том, что в задачах, где разработчикам нужно именно качество, а не только скорость, выбор чаще падает на модель от Anthropic.
Сам пользуюсь Cursor и на своем опыте могу точно сказать, что пока в разработке для ежедневных задач программистов одна из самых предпочтительных моделей по цена/качество — Claude 4 Sonnet. Ребята из Anthropic молодцы, но это не конец. Думаю ситуация не статична и время от времени лидеры будут меняться. Тем лучше для обычных пользователей.
Вот так выглядит ТОП-10 моделей в статистике за неделю на сайте OpenRouter https://vk.cc/cOiVWB
Можно заметить, что если сложить все модели от Google, то они суммарно занимают первое место. Но в этих рассуждениях есть одно «но». Модели Gemini 2.0 и 2.5 Flash — это очень быстрые и дешевые модели, которые, как правило, используют не для разработки, а для небольших задач. А вот Gemini 2.5 Pro — это прямой конкурент для Anthropic Claude 4 Sonnet, и здесь отчетливо видно, что у Anthropic 4-кратное преимущество перед Google за счет качества модели у разработчиков. Это говорит о том, что в задачах, где разработчикам нужно именно качество, а не только скорость, выбор чаще падает на модель от Anthropic.
Сам пользуюсь Cursor и на своем опыте могу точно сказать, что пока в разработке для ежедневных задач программистов одна из самых предпочтительных моделей по цена/качество — Claude 4 Sonnet. Ребята из Anthropic молодцы, но это не конец. Думаю ситуация не статична и время от времени лидеры будут меняться. Тем лучше для обычных пользователей.
Кейс: Как сократить время замены картриджа с 2 дней до 10 минут без дополнительных затрат
На одной из конференции Infostart Event услышал управленческий кейс от коллеги, ИТ-директора Сергея Горшенина, который идеально иллюстрирует принцип «гениальное — просто».
🔥 Проблема: два дня на замену картриджа
Представьте крупное предприятие с территорией, по которой сотрудники передвигаются на автобусах. IT-отдел небольшой. Когда у кого-то заканчивается тонер, особенно в отчетный период, появляется проблема. Специалист тратит время на дорогу, чтобы просто поменять картридж. В итоге рабочее место простаивает день, а то и два.
IT-отдел превращается в курьерскую службу, а бизнес теряет время.
Прежде чем читать дальше, поставьте себя на место руководителя. Какое нетехническое, управленческое решение вы бы приняли, не имея бюджета на расширение штата?
<...пауза на подумать...>
💡 Решение: изменить парадигму
Ключевая мысль, к которой пришел Сергей, была простой: кто быстрее всех узнает, что картридж закончился? Сам пользователь. А что, если он сам его и принесет?
Схема была реализована в три шага:
1. Создание ценности. Пользователям, которые жаловались на простой, задавали вопрос: «Хотите, чтобы замена картриджа занимала 10 минут вместо двух дней?». Ответ был очевиден.
2. Разовое обучение. В обмен на скорость специалист IT один раз приезжал к пользователю и обучал его простому действию: как вынуть картридж из МФУ и вставить новый.
3. Организация «обменного пункта». На складе IT-отдела был создан резерв картриджей. Теперь пользователь сам приносил пустой картридж и мгновенно получал заправленный. Никаких поездок со стороны IT, никаких простоев.
🤔 Вывод
На мой взгляд, гениальность этого решения — в смене парадигмы. Вместо того чтобы оптимизировать неэффективный процесс (как специалисту быстрее ездить?), его полностью перестроили, задав правильные вопросы:
- Кто владелец проблемы? Пользователь.
- Какую ценность мы можем ему предложить? Скорость.
- Что мы просим взамен? Простое действие, которое экономит всем кучу времени.
Как говорил Сергей Королев: «Каждый может сделать сложно, а ты попробуй сделать просто». Этот кейс — прямое тому доказательство.
Интересное решение.
#Бизнес_КИД #Кейсы_КИД
На одной из конференции Infostart Event услышал управленческий кейс от коллеги, ИТ-директора Сергея Горшенина, который идеально иллюстрирует принцип «гениальное — просто».
🔥 Проблема: два дня на замену картриджа
Представьте крупное предприятие с территорией, по которой сотрудники передвигаются на автобусах. IT-отдел небольшой. Когда у кого-то заканчивается тонер, особенно в отчетный период, появляется проблема. Специалист тратит время на дорогу, чтобы просто поменять картридж. В итоге рабочее место простаивает день, а то и два.
IT-отдел превращается в курьерскую службу, а бизнес теряет время.
Прежде чем читать дальше, поставьте себя на место руководителя. Какое нетехническое, управленческое решение вы бы приняли, не имея бюджета на расширение штата?
<...пауза на подумать...>
💡 Решение: изменить парадигму
Ключевая мысль, к которой пришел Сергей, была простой: кто быстрее всех узнает, что картридж закончился? Сам пользователь. А что, если он сам его и принесет?
Схема была реализована в три шага:
1. Создание ценности. Пользователям, которые жаловались на простой, задавали вопрос: «Хотите, чтобы замена картриджа занимала 10 минут вместо двух дней?». Ответ был очевиден.
2. Разовое обучение. В обмен на скорость специалист IT один раз приезжал к пользователю и обучал его простому действию: как вынуть картридж из МФУ и вставить новый.
3. Организация «обменного пункта». На складе IT-отдела был создан резерв картриджей. Теперь пользователь сам приносил пустой картридж и мгновенно получал заправленный. Никаких поездок со стороны IT, никаких простоев.
🤔 Вывод
На мой взгляд, гениальность этого решения — в смене парадигмы. Вместо того чтобы оптимизировать неэффективный процесс (как специалисту быстрее ездить?), его полностью перестроили, задав правильные вопросы:
- Кто владелец проблемы? Пользователь.
- Какую ценность мы можем ему предложить? Скорость.
- Что мы просим взамен? Простое действие, которое экономит всем кучу времени.
Как говорил Сергей Королев: «Каждый может сделать сложно, а ты попробуй сделать просто». Этот кейс — прямое тому доказательство.
Интересное решение.
#Бизнес_КИД #Кейсы_КИД
Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова
По студенчеству я, как и любой джун, совершал ошибки. Одна из них — классический пример истины «работает — не трожь».
2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.
Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.
А я молодой, амбициозный и несу людям счастье)))
Я тогда подумал. Почему они мучаются с этим бесконечным тредом сообщений? Это же жутко неудобно! А что если я уберу эту гостевую книгу и заменю ее на удобный форум для своих? Хорошая же идея? Ну, если судить логически, то да. Свой форум, регистрация, понятно, кто пишет, можно делать свои темы и не тонуть в бесконечной беседе. На тот момент мне казалось, что это отличная идея сделать жизнь определенного круга людей лучше.
Нашел хороший движок форума и в один прекрасный день заменил гостевую книгу на этот форум. Создал темы и стал ждать, как мне люди скажут спасибо.
Догадываетесь, что было дальше? )))
Правильно. Провал… Ученики не стали использовать новый форум!
Была попытка одного человека что-то написать, но когда никто не ответил, то и он перестал что-то писать + пара регистраций пользователей. Моя попытка это исправить ни к чему не привела. Я даже старые сообщения пользователей из гостевой книги загрузил в новый форум. Все бестолку. Сайт, у которого был отличный трафик, буквально за неделю перестали посещать.
Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?
Как всегда, рефлексия и мои мысли на эту тему прилагаются:
- Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.
- Если какой-то сервис работает хорошо, но, на твой взгляд, там все организовано очень нелогично, не надо это исправлять сию минуту! Надо сделать опрос, проверить гипотезы, попробовать узнать мнение пользователей. Бывает, конечно, и такое, что пользователи не могут тебе сказать, что нужно добавить, и при добавлении этого «чего-то» оно действительно взлетает, но делать это нужно аккуратно, просчитывая варианты.
- Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда в Софтонит предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую «ламповость», просто заменив ее на «правильное» решение?»
Вот такая история.
P. S. Если кто-то читает мой пост из тех, кто тогда сидел в этой гостевой книге, прошу у вас прощения. Я не хотел, чтобы так все вышло.
#Истории_КИД #РазборПродукта_КИД
По студенчеству я, как и любой джун, совершал ошибки. Одна из них — классический пример истины «работает — не трожь».
2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.
Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.
А я молодой, амбициозный и несу людям счастье)))
Я тогда подумал. Почему они мучаются с этим бесконечным тредом сообщений? Это же жутко неудобно! А что если я уберу эту гостевую книгу и заменю ее на удобный форум для своих? Хорошая же идея? Ну, если судить логически, то да. Свой форум, регистрация, понятно, кто пишет, можно делать свои темы и не тонуть в бесконечной беседе. На тот момент мне казалось, что это отличная идея сделать жизнь определенного круга людей лучше.
Нашел хороший движок форума и в один прекрасный день заменил гостевую книгу на этот форум. Создал темы и стал ждать, как мне люди скажут спасибо.
Догадываетесь, что было дальше? )))
Правильно. Провал… Ученики не стали использовать новый форум!
Была попытка одного человека что-то написать, но когда никто не ответил, то и он перестал что-то писать + пара регистраций пользователей. Моя попытка это исправить ни к чему не привела. Я даже старые сообщения пользователей из гостевой книги загрузил в новый форум. Все бестолку. Сайт, у которого был отличный трафик, буквально за неделю перестали посещать.
Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?
Как всегда, рефлексия и мои мысли на эту тему прилагаются:
- Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.
- Если какой-то сервис работает хорошо, но, на твой взгляд, там все организовано очень нелогично, не надо это исправлять сию минуту! Надо сделать опрос, проверить гипотезы, попробовать узнать мнение пользователей. Бывает, конечно, и такое, что пользователи не могут тебе сказать, что нужно добавить, и при добавлении этого «чего-то» оно действительно взлетает, но делать это нужно аккуратно, просчитывая варианты.
- Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда в Софтонит предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую «ламповость», просто заменив ее на «правильное» решение?»
Вот такая история.
P. S. Если кто-то читает мой пост из тех, кто тогда сидел в этой гостевой книге, прошу у вас прощения. Я не хотел, чтобы так все вышло.
#Истории_КИД #РазборПродукта_КИД
🔥2
30 лет без дизайна и миллиард в кассе
На днях я рассказывал историю о том, как в 2004-м «улучшил» простую гостевую книгу, заменив ее на «правильный» форум и этим убил живое сообщество. Главный вывод был в том, что нельзя ломать работающую систему, не поняв, какую настоящую задачу она решает для пользователей.
А сегодня я наткнулся на статью на VC.ru, которая служит идеальной иллюстрацией этого принципа в промышленных масштабах. Речь о Craigslist.
Ссылка на статью: Craigslist — древнейший стартап с миллиардной выручкой
Для тех, кто не в курсе: Craigslist — это что-то типа Авито, но в США, т.е. такая гигантская доска объявлений. Ее дизайн застрял где-то в 1998 году: синие ссылки, простейшая верстка, ноль графики. По любым современным меркам UI/UX — это катастрофа. При этом компания с крошечной командой зарабатывает сотни миллионов (а по некоторым оценкам — более миллиарда) долларов в год. Работает там от силы 50 человек (!) Если пересчитаем выручку, то окажется, что на каждого сотрудника приходится 4 млн. долларов в год (!) 🤯 Очень круто!
И тут я смотрю на Craigslist и понимаю: их «ужасный» сайт — это моя «неудобная» гостевая книга, только в масштабе всей Америки. Они поняли то, чего не понял я в 20 лет, и не стали «чинить» то, что не сломано.
Почему этот «примитивный» дизайн работает и приносит миллиарды?
- Скорость. Сайт загружается мгновенно. Нет тяжелых фреймворков, мегабайтов JavaScript и аналитических скриптов. Чистая функция.
- Плотность информации. Никаких баннеров, всплывающих окон и модных карточек. Только текст и ссылки. Вы видите максимум полезной информации на одном экране.
- Отсутствие трения. Хочешь разместить объявление? Нажимай и размещай. Не нужна регистрация (как я понял), подтверждение почты и двухфакторная аутентификация, чтобы продать старый стул. Сервис не мешает тебе делать то, зачем ты пришел.
- Привычка. Миллионы людей пользуются им десятилетиями. Они знают каждую ссылку наизусть. Любой редизайн вызовет у этой аудитории не восторг, а гнев. Они потеряют свой привычный и предсказуемый инструмент.
Мой «улучшенный» форум вводил трение: регистрация, создание тем, сложная структура. Я убил легкость и анонимность. Точно так же любой «современный» редизайн Craigslist с React, модными анимациями и персонализацией убьет его главное преимущество — скорость и простоту.
Вывод для любого IT-руководителя:
Это вечный соблазн для любого технаря — переписать старое, «кривое», но работающее легаси на новый, блестящий стек. Нам кажется, что мы сделаем «лучше». Но главный вопрос: «лучше» для кого? Для вас или для пользователя, который просто хочет за 3 секунды решить свою задачу?
Craigslist — это гениальный пример бизнес-прагматизма. Он доказывает, что иногда лучшая фича — это ее отсутствие. А самый ценный актив компании — это привычка пользователя, которую нельзя ломать без крайней необходимости.
А в вашей практике есть свой внутренний «Craigslist»? Старый, неудобный, но незаменимый сервис, который все мечтают переписать, но боятся трогать?
#Истории_КИД #Бизнес_КИД
На днях я рассказывал историю о том, как в 2004-м «улучшил» простую гостевую книгу, заменив ее на «правильный» форум и этим убил живое сообщество. Главный вывод был в том, что нельзя ломать работающую систему, не поняв, какую настоящую задачу она решает для пользователей.
А сегодня я наткнулся на статью на VC.ru, которая служит идеальной иллюстрацией этого принципа в промышленных масштабах. Речь о Craigslist.
Ссылка на статью: Craigslist — древнейший стартап с миллиардной выручкой
Для тех, кто не в курсе: Craigslist — это что-то типа Авито, но в США, т.е. такая гигантская доска объявлений. Ее дизайн застрял где-то в 1998 году: синие ссылки, простейшая верстка, ноль графики. По любым современным меркам UI/UX — это катастрофа. При этом компания с крошечной командой зарабатывает сотни миллионов (а по некоторым оценкам — более миллиарда) долларов в год. Работает там от силы 50 человек (!) Если пересчитаем выручку, то окажется, что на каждого сотрудника приходится 4 млн. долларов в год (!) 🤯 Очень круто!
И тут я смотрю на Craigslist и понимаю: их «ужасный» сайт — это моя «неудобная» гостевая книга, только в масштабе всей Америки. Они поняли то, чего не понял я в 20 лет, и не стали «чинить» то, что не сломано.
Почему этот «примитивный» дизайн работает и приносит миллиарды?
- Скорость. Сайт загружается мгновенно. Нет тяжелых фреймворков, мегабайтов JavaScript и аналитических скриптов. Чистая функция.
- Плотность информации. Никаких баннеров, всплывающих окон и модных карточек. Только текст и ссылки. Вы видите максимум полезной информации на одном экране.
- Отсутствие трения. Хочешь разместить объявление? Нажимай и размещай. Не нужна регистрация (как я понял), подтверждение почты и двухфакторная аутентификация, чтобы продать старый стул. Сервис не мешает тебе делать то, зачем ты пришел.
- Привычка. Миллионы людей пользуются им десятилетиями. Они знают каждую ссылку наизусть. Любой редизайн вызовет у этой аудитории не восторг, а гнев. Они потеряют свой привычный и предсказуемый инструмент.
Мой «улучшенный» форум вводил трение: регистрация, создание тем, сложная структура. Я убил легкость и анонимность. Точно так же любой «современный» редизайн Craigslist с React, модными анимациями и персонализацией убьет его главное преимущество — скорость и простоту.
Вывод для любого IT-руководителя:
Это вечный соблазн для любого технаря — переписать старое, «кривое», но работающее легаси на новый, блестящий стек. Нам кажется, что мы сделаем «лучше». Но главный вопрос: «лучше» для кого? Для вас или для пользователя, который просто хочет за 3 секунды решить свою задачу?
Craigslist — это гениальный пример бизнес-прагматизма. Он доказывает, что иногда лучшая фича — это ее отсутствие. А самый ценный актив компании — это привычка пользователя, которую нельзя ломать без крайней необходимости.
А в вашей практике есть свой внутренний «Craigslist»? Старый, неудобный, но незаменимый сервис, который все мечтают переписать, но боятся трогать?
#Истории_КИД #Бизнес_КИД
vc.ru
Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова — Истории на vc.ru
Код ИТ-директора Истории 11 авг
👏2😱2👍1🔥1
Качество техподдержки падает из-за нейросетей
Помните, был такой лайфхак, когда для связи с оператором Сбера просили бота ответить на вопрос «период полураспада радия/плутония» и бот в панике сразу переводил на оператора? Потом это пофиксили, но я этот случай запомнил.
На днях увидел, что ребята на Reddit обсуждают такую же проблему: корпоративная техподдержка вендоров стала хуже. Ответы операторов шаблонные, реального понимания проблемы нет, решение растягивается на недели, а виной тому дешевые сотрудники и нейросети.
Честно говоря, это не только про вендоров. Та же тенденция есть в любой IT-техподдержке — от SaaS-сервисов до внутренних helpdesk, ну и Сбер тоже не исключение. На мой взгляд, причин несколько:
- Сокращение расходов и оптимизация штата. А это уже следствие подключения к техподдержке нейросетей. Руководство видит возможность сократить затраты (считай, заработать).
- Ставка на «среднего» специалиста, а не эксперта. Задумка хорошая, что средний спец + нейросеть = эксперт, но вот на практике это почти всегда не так.
- Увлечение автоматизацией и «ботизацией» без продуманной логики. Нейросети поумнели, и почему бы их не использовать на полную катушку?
После появления в техподдержке LLM многое поменялось. В теории отличная штука: нейросеть может за секунды найти ответ в базе знаний. На практике мы получаем красивый текст (или голос), который звучит как решение, но не решает проблему, а заставляет обратившегося клиента уточнять какие-то вопросы, повторять одно и тоже, как попугай, и каждый раз начинать диалог заново. Так происходит потому что:
- Модель не понимает контекст, если вопрос нестандартный.
- Она «галлюцинирует» там, где не знает ответа.
- Клиент тратит время на проверку, а не на решение.
Я думаю, что ситуация будет усугубляться: всё больше компаний будут пытаться экономить, заменяя первую линию поддержки на чат-бота с LLM. Это общий тренд. И вместо того, чтобы решить проблему за 10 минут с инженером, клиент будет три раза «объяснять заново», прежде чем добьётся связи с человеком.
Отказаться от LLM нельзя — они действительно ускоряют работу, особенно в рутинных и повторяющихся задачах. Но и пускать их в продакшн без правил — самоубийство для репутации техподдержки.
Я думаю вот о чем:
- LLM как ассистент, а не как фронт. Модель подсказывает оператору варианты решения, а не отвечает напрямую клиенту.
- Вопросы с высокой ценой ошибки — только через человека. Автоматизация — да, но с триггерами для эскалации.
- Контекст — главное. Не подсовывать LLM голый вопрос, а давать историю обращений, конфигурацию системы, логи.
- Метрики качества. Замерять не скорость ответа, а количество обращений, которые закрыты «с первого раза».
Вопрос в том, когда и как компании это будут делать правильно? Потому что гонка «а сэкономим-ка ещё бюджет» легко превратит службу поддержки в чат, от которого клиент убегает к конкурентам.
Это даже хуже, чем общаться с ИИ напрямую — ведь ты тратишь время на человека, который просто пересказывает твой вопрос ИИ. Задача для ИТ — не дать клиенту испытать это чувство. Хорошая техподдержка — это про доверие. И если клиент почувствует, что его время тратят впустую, вернуть его будет невозможно.
Было бы интересно обсудить с теми, кто из ИТ, как это организовано у Вас с техподдержкой? Да и вообще, кто что думает по этому поводу?
https://codeitdir.ru/news/kachestvo-tehpodderzhki-padaet-iz-za-neyrosetey/?utm_source=Telegram&utm_medium=social&utm_campaign=25888278
#Истории_КИД
Помните, был такой лайфхак, когда для связи с оператором Сбера просили бота ответить на вопрос «период полураспада радия/плутония» и бот в панике сразу переводил на оператора? Потом это пофиксили, но я этот случай запомнил.
На днях увидел, что ребята на Reddit обсуждают такую же проблему: корпоративная техподдержка вендоров стала хуже. Ответы операторов шаблонные, реального понимания проблемы нет, решение растягивается на недели, а виной тому дешевые сотрудники и нейросети.
Честно говоря, это не только про вендоров. Та же тенденция есть в любой IT-техподдержке — от SaaS-сервисов до внутренних helpdesk, ну и Сбер тоже не исключение. На мой взгляд, причин несколько:
- Сокращение расходов и оптимизация штата. А это уже следствие подключения к техподдержке нейросетей. Руководство видит возможность сократить затраты (считай, заработать).
- Ставка на «среднего» специалиста, а не эксперта. Задумка хорошая, что средний спец + нейросеть = эксперт, но вот на практике это почти всегда не так.
- Увлечение автоматизацией и «ботизацией» без продуманной логики. Нейросети поумнели, и почему бы их не использовать на полную катушку?
После появления в техподдержке LLM многое поменялось. В теории отличная штука: нейросеть может за секунды найти ответ в базе знаний. На практике мы получаем красивый текст (или голос), который звучит как решение, но не решает проблему, а заставляет обратившегося клиента уточнять какие-то вопросы, повторять одно и тоже, как попугай, и каждый раз начинать диалог заново. Так происходит потому что:
- Модель не понимает контекст, если вопрос нестандартный.
- Она «галлюцинирует» там, где не знает ответа.
- Клиент тратит время на проверку, а не на решение.
Я думаю, что ситуация будет усугубляться: всё больше компаний будут пытаться экономить, заменяя первую линию поддержки на чат-бота с LLM. Это общий тренд. И вместо того, чтобы решить проблему за 10 минут с инженером, клиент будет три раза «объяснять заново», прежде чем добьётся связи с человеком.
Отказаться от LLM нельзя — они действительно ускоряют работу, особенно в рутинных и повторяющихся задачах. Но и пускать их в продакшн без правил — самоубийство для репутации техподдержки.
Я думаю вот о чем:
- LLM как ассистент, а не как фронт. Модель подсказывает оператору варианты решения, а не отвечает напрямую клиенту.
- Вопросы с высокой ценой ошибки — только через человека. Автоматизация — да, но с триггерами для эскалации.
- Контекст — главное. Не подсовывать LLM голый вопрос, а давать историю обращений, конфигурацию системы, логи.
- Метрики качества. Замерять не скорость ответа, а количество обращений, которые закрыты «с первого раза».
Вопрос в том, когда и как компании это будут делать правильно? Потому что гонка «а сэкономим-ка ещё бюджет» легко превратит службу поддержки в чат, от которого клиент убегает к конкурентам.
Это даже хуже, чем общаться с ИИ напрямую — ведь ты тратишь время на человека, который просто пересказывает твой вопрос ИИ. Задача для ИТ — не дать клиенту испытать это чувство. Хорошая техподдержка — это про доверие. И если клиент почувствует, что его время тратят впустую, вернуть его будет невозможно.
Было бы интересно обсудить с теми, кто из ИТ, как это организовано у Вас с техподдержкой? Да и вообще, кто что думает по этому поводу?
https://codeitdir.ru/news/kachestvo-tehpodderzhki-padaet-iz-za-neyrosetey/?utm_source=Telegram&utm_medium=social&utm_campaign=25888278
#Истории_КИД
Reddit
From the sysadmin community on Reddit
Explore this post and more from the sysadmin community
🔥1🐳1
Переход 1С на PostgreSQL и прогнозы до 2031 года
Ни для кого не секрет, что клиент-серверный вариант 1С изначально затачивался под MS SQL. Вспоминаю год 2017-ый и точно помню, что в тот момент Postgres ставили в основном те компании, которые хотели сэкономить. Плевались, но использовали. Чуть более или менее серьезная нагрузка — и всё.
Помню, как мы для «Управления IT-отделом 8» написали расчет SLA по графикам техподдержки. На файловой базе и в MS SQL все работало прекрасно. Выпустили обновление, но один клиент на Postgres начал жаловаться. Долго выясняли, в чем дело. В конечном итоге я подключился к нему на тестовый сервер, прошелся отладчиком и… бинго! Действительно наша ошибка: не указали сортировку в одном из вложенных запросов. На файловой и на MS SQL такой запрос, повторю, работал отлично. Postgres в этом деле оказался строже — сказано в документации, что выборка не гарантирует порядок? Будьте добры предусмотрите это.
Эта история из прошлого отлично иллюстрирует те же проблемы, с которыми бизнес сталкивается сегодня, когда переход стал практически неизбежным.
Если коротко, то вот главные грабли, на которые наступают при миграции 1С на PostgreSQL:
Проблема №1: Деградация производительности. Миграция «в лоб» почти всегда приводит к проблемам с блокировками и работой планировщика запросов. Приходится переписывать код и оптимизировать его под PostgreSQL. Возможно, даже менять что-то в самой платформе.
Проблема №2: Кадры. Найти опытного DBA по Postgres, который глубоко понимает специфику 1С, значительно сложнее и дороже. С MS SQL всё было проще: установил, клик, клик — готово. Даже без тонких настроек многое работало «из коробки».
Ну и самое главное: миграция — это не просто смена СУБД. Это полноценный проект, требующий тестирования, переписывания узких мест в коде и, возможно, обучения команды. Экономия на лицензиях может быть полностью съедена затратами на внедрение и поддержку (да и не сказал бы, что тот же Postgres Pro дешевый).
А теперь о том, почему этот разговор вообще имеет смысл.
Раньше мы всегда советовали клиентам MS SQL как надежную и проверенную СУБД. Да, в 2015-ом появился платный Postgres Pro, но, честно сказать, мы его всерьез не рассматривали. Зачем, если есть деньги на проверенный MS SQL? А если хотелось сэкономить — был бесплатный Postgres со всеми его тогдашними особенностями.
Но потом пришел 2022-ой год, санкции вендоров и постепенная миграция стала трендом. А сейчас это уже не вопрос выбора, а вопрос времени.
Это не просто ощущения, это подтверждают цифры из исследования ЦСР. Уже в 2024 году на новые продажи зарубежного ПО пришлось всего ~10% рынка. Прогноз до 2031 года следующий: российские решения для работы с базами данных могут занять до 99% новых продаж (!) Процесс импортозамещения будет идти, а если мы берем 1С, то тут в выигрыше PostgreSQL/Postgres Pro. Причины понятны: уход западных вендоров, требования регуляторов и развитие отечественных продуктов.
Для компаний использующих 1С это означает полный стратегический переход на Postgres в ближайшие годы. Но, как показывает практика, делать это нужно с умом.
У меня вопрос. Планируете переход на PostgreSQL или, как и мы, пока живете на старом софте?
Подробнее в моем блоге: https://codeitdir.ru/news/perehod-1s-na-postgresql-i-prognozy-do-2031-goda/?utm_source=Telegram&utm_medium=social&utm_campaign=25858638
#РазборПродукта_КИД #Бизнес_КИД #Кейсы_КИД #Истории_КИД
Ни для кого не секрет, что клиент-серверный вариант 1С изначально затачивался под MS SQL. Вспоминаю год 2017-ый и точно помню, что в тот момент Postgres ставили в основном те компании, которые хотели сэкономить. Плевались, но использовали. Чуть более или менее серьезная нагрузка — и всё.
Помню, как мы для «Управления IT-отделом 8» написали расчет SLA по графикам техподдержки. На файловой базе и в MS SQL все работало прекрасно. Выпустили обновление, но один клиент на Postgres начал жаловаться. Долго выясняли, в чем дело. В конечном итоге я подключился к нему на тестовый сервер, прошелся отладчиком и… бинго! Действительно наша ошибка: не указали сортировку в одном из вложенных запросов. На файловой и на MS SQL такой запрос, повторю, работал отлично. Postgres в этом деле оказался строже — сказано в документации, что выборка не гарантирует порядок? Будьте добры предусмотрите это.
Эта история из прошлого отлично иллюстрирует те же проблемы, с которыми бизнес сталкивается сегодня, когда переход стал практически неизбежным.
Если коротко, то вот главные грабли, на которые наступают при миграции 1С на PostgreSQL:
Проблема №1: Деградация производительности. Миграция «в лоб» почти всегда приводит к проблемам с блокировками и работой планировщика запросов. Приходится переписывать код и оптимизировать его под PostgreSQL. Возможно, даже менять что-то в самой платформе.
Проблема №2: Кадры. Найти опытного DBA по Postgres, который глубоко понимает специфику 1С, значительно сложнее и дороже. С MS SQL всё было проще: установил, клик, клик — готово. Даже без тонких настроек многое работало «из коробки».
Ну и самое главное: миграция — это не просто смена СУБД. Это полноценный проект, требующий тестирования, переписывания узких мест в коде и, возможно, обучения команды. Экономия на лицензиях может быть полностью съедена затратами на внедрение и поддержку (да и не сказал бы, что тот же Postgres Pro дешевый).
А теперь о том, почему этот разговор вообще имеет смысл.
Раньше мы всегда советовали клиентам MS SQL как надежную и проверенную СУБД. Да, в 2015-ом появился платный Postgres Pro, но, честно сказать, мы его всерьез не рассматривали. Зачем, если есть деньги на проверенный MS SQL? А если хотелось сэкономить — был бесплатный Postgres со всеми его тогдашними особенностями.
Но потом пришел 2022-ой год, санкции вендоров и постепенная миграция стала трендом. А сейчас это уже не вопрос выбора, а вопрос времени.
Это не просто ощущения, это подтверждают цифры из исследования ЦСР. Уже в 2024 году на новые продажи зарубежного ПО пришлось всего ~10% рынка. Прогноз до 2031 года следующий: российские решения для работы с базами данных могут занять до 99% новых продаж (!) Процесс импортозамещения будет идти, а если мы берем 1С, то тут в выигрыше PostgreSQL/Postgres Pro. Причины понятны: уход западных вендоров, требования регуляторов и развитие отечественных продуктов.
Для компаний использующих 1С это означает полный стратегический переход на Postgres в ближайшие годы. Но, как показывает практика, делать это нужно с умом.
У меня вопрос. Планируете переход на PostgreSQL или, как и мы, пока живете на старом софте?
Подробнее в моем блоге: https://codeitdir.ru/news/perehod-1s-na-postgresql-i-prognozy-do-2031-goda/?utm_source=Telegram&utm_medium=social&utm_campaign=25858638
#РазборПродукта_КИД #Бизнес_КИД #Кейсы_КИД #Истории_КИД
www.csr.ru
Объем рынка СУБД к 2031 году превысит 251 млрд рублей
Центр стратегических разработок провел ежегодное исследование рынка систем управления базами данных (СУБД) и инструментов обработки данных за 2024 год и уточнил прогноз до 2031 года. По словам заместителя генерального директора ЦСР Екатерины Кваши, «ожидается...
😈1
1С и цвет. Как из одной строчки HEX-кода выросла целая библиотека
Все началось с банальной задачи. Я хотел нормально сохранять настройки цветов в конфигурации «Управление IT-отделом 8».
В веб-разработке все привыкли к формату вроде
Пришлось написать пару небольших функций. А потом закрутилось. Раз уж я работаю с HEX, почему бы не добавить смешивание цветов? А потом генерацию случайных оттенков для диаграмм? А потом градиенты?
Так маленький «велосипед» постепенно оброс фичами и превратился в полноценную библиотеку color1c. Я понял, что решаю не только свою проблему, и выложил инструмент в опенсорс.
➡️ Ссылка на GitHub, забирайте: https://github.com/Diversus23/color1c?utm_source=Telegram&utm_medium=social&utm_campaign=25917325
Что умеет инструмент, если коротко
- Полная конвертация Преобразование между
- Манипуляции с цветом Смешивание нескольких цветов, получение контрастного или инвертированного цвета, градации серого.
- Получение случайных светлых или темных оттенков, что идеально для диаграмм и графиков.
- Каталоги Встроена работа с каталогами RAL, пастельные цвета и т.д. При этом можно легко добавлять свои.
- Градиенты Расчет градиентного перехода между двумя и более цветами.
- …
Почему это важно не только для разработчика
Этот инструмент не просто для кодеров, он решает три важные задачи для руководителя.
- Экономия ресурсов. Ваши разработчики перестают тратить часы на написание однотипного кода. Они берут готовую, отлаженную библиотеку и занимаются бизнес-задачей, а не технической рутиной.
- Единый стандарт. У вас появляется один инструмент вместо десятка разных самописных реализаций. Это сильно упрощает код-ревью, поддержку и развитие всей системы.
- Качество UX. Удобная работа с цветом позволяет быстро и без боли кастомизировать интерфейс. А хороший UI, как мы знаем, это не просто «красивости». Он снижает количество ошибок пользователя и повышает его производительность.
Мы у себя в «Управлении IT-отделом 8» уже давно перевели всю работу с цветом на этот механизм. Окупилось многократно.
Буду рад, если инструмент окажется полезным и вам. Если есть идеи по доработке или желание внести свой вклад, pull request на GitHub горячо приветствуются.
Запись в моем блоге https://codeitdir.ru/tools/color1c/?utm_source=Telegram&utm_medium=social&utm_campaign=25917325
#1C #OpenSource #DevTools #Разработка1С
#Бизнес_КИД #УправлениеИТОтделом8_КИД #Инструменты_КИД
Все началось с банальной задачи. Я хотел нормально сохранять настройки цветов в конфигурации «Управление IT-отделом 8».
В веб-разработке все привыкли к формату вроде
#FABC01. Мне показалось логичным использовать его и в 1С. Это просто, понятно и универсально. Но оказалось, что в платформе нет готовых функций для конвертации такого формата в стандартный тип Цвет. И обратно.Пришлось написать пару небольших функций. А потом закрутилось. Раз уж я работаю с HEX, почему бы не добавить смешивание цветов? А потом генерацию случайных оттенков для диаграмм? А потом градиенты?
Так маленький «велосипед» постепенно оброс фичами и превратился в полноценную библиотеку color1c. Я понял, что решаю не только свою проблему, и выложил инструмент в опенсорс.
➡️ Ссылка на GitHub, забирайте: https://github.com/Diversus23/color1c?utm_source=Telegram&utm_medium=social&utm_campaign=25917325
Что умеет инструмент, если коротко
- Полная конвертация Преобразование между
Цвет1С, HEX, RGB, CMYK, HSV и HSL.- Манипуляции с цветом Смешивание нескольких цветов, получение контрастного или инвертированного цвета, градации серого.
- Получение случайных светлых или темных оттенков, что идеально для диаграмм и графиков.
- Каталоги Встроена работа с каталогами RAL, пастельные цвета и т.д. При этом можно легко добавлять свои.
- Градиенты Расчет градиентного перехода между двумя и более цветами.
- …
Почему это важно не только для разработчика
Этот инструмент не просто для кодеров, он решает три важные задачи для руководителя.
- Экономия ресурсов. Ваши разработчики перестают тратить часы на написание однотипного кода. Они берут готовую, отлаженную библиотеку и занимаются бизнес-задачей, а не технической рутиной.
- Единый стандарт. У вас появляется один инструмент вместо десятка разных самописных реализаций. Это сильно упрощает код-ревью, поддержку и развитие всей системы.
- Качество UX. Удобная работа с цветом позволяет быстро и без боли кастомизировать интерфейс. А хороший UI, как мы знаем, это не просто «красивости». Он снижает количество ошибок пользователя и повышает его производительность.
Мы у себя в «Управлении IT-отделом 8» уже давно перевели всю работу с цветом на этот механизм. Окупилось многократно.
Буду рад, если инструмент окажется полезным и вам. Если есть идеи по доработке или желание внести свой вклад, pull request на GitHub горячо приветствуются.
Запись в моем блоге https://codeitdir.ru/tools/color1c/?utm_source=Telegram&utm_medium=social&utm_campaign=25917325
#1C #OpenSource #DevTools #Разработка1С
#Бизнес_КИД #УправлениеИТОтделом8_КИД #Инструменты_КИД
GitHub
GitHub - Diversus23/color1c: Универсальные функции для работы с цветом в 1С
Универсальные функции для работы с цветом в 1С. Contribute to Diversus23/color1c development by creating an account on GitHub.
🔥2🤣1
Больше года моя команда работала над новой версией «Управление IT-отделом». Сегодня я готов показать, что у нас получилось. Это не просто обновление, а полная пересборка продукта.
TL;DR: Выжимка
❗ Главное: Мы убили громоздкую связку «Проект → Процесс → Этап». Теперь есть только гибкие Проекты с настраиваемыми колонками (разделами), как в Trello или Jira. Стало на порядок проще и логичнее.
🔥 Права доступа: Полностью переписали RLS. Теперь доступ определяется участием в проекте, а не сложной иерархией подчиненности. Идеально для матричных команд.
📱 Мобильное приложение: Выбросили старое на технологиях 1С и написали новое с нуля на Flutter. Оно нативное, быстрое, и push-уведомления теперь работают как часы.
🤖 AI-ассистент: Встраиваем ИИ, который превращает технические комментарии инженера в вежливые ответы для пользователей и помогает структурировать задачи. Меньше рутины, больше дела.
👉 Подробнее на https://codeitdir.ru/other/uit-4-0-anonce/?utm_source=Telegram&utm_medium=social&utm_campaign=25972109
#РазборПродукта_КИД
TL;DR: Выжимка
❗ Главное: Мы убили громоздкую связку «Проект → Процесс → Этап». Теперь есть только гибкие Проекты с настраиваемыми колонками (разделами), как в Trello или Jira. Стало на порядок проще и логичнее.
🔥 Права доступа: Полностью переписали RLS. Теперь доступ определяется участием в проекте, а не сложной иерархией подчиненности. Идеально для матричных команд.
📱 Мобильное приложение: Выбросили старое на технологиях 1С и написали новое с нуля на Flutter. Оно нативное, быстрое, и push-уведомления теперь работают как часы.
🤖 AI-ассистент: Встраиваем ИИ, который превращает технические комментарии инженера в вежливые ответы для пользователей и помогает структурировать задачи. Меньше рутины, больше дела.
👉 Подробнее на https://codeitdir.ru/other/uit-4-0-anonce/?utm_source=Telegram&utm_medium=social&utm_campaign=25972109
#РазборПродукта_КИД
Код ИТ-директора | Барилко Виталий
Упростить, а не усложнить. Как мы убили половину функций в ITSM-системе, чтобы она наконец-то заработала как надо - Код ИТ-директора…
Анонс новости выпуска новой версии Управление IT-отделом 8, редакция 4.0
🤩3🔥1
Many-Notes: Простые заметки в Markdown на своем сервере.
Наткнулся на Reddit на небольшой, но очень интересный проект для тех, кто любит полный контроль над своими данными и ценит минимализм. Это self-hosted приложение для заметок Many-Notes.
TL;DR: Коротко о главном
💡 Что это? Опенсорсное web-приложение для работы с Markdown-записями, спроектированное с акцентом на минимализм и полный контроль над данными. Вы разворачиваете его у себя (self-hosted).
✅ Главная фишка: Использует базу данных (SQLite по умолчанию, но поддерживается MariaDB, MySQL и PostgreSQL) для продвинутых функций вроде многопользовательности и быстрого поиска, но при этом все заметки физически лежат в виде .md файлов. База нужна не для хранения текста заметок, а для метаданных, пользователей и индексации поиска.
🚀 Технологии: Написано на PHP, рассчитано на простую установку через Docker.
🤔 Кому зайдет? Небольшим командам или продвинутым пользователям, которым нужна своя база знаний с совместной работой, но без привязки к конкретному сервису.
Что под капотом? Ключевые возможности:
- Это не просто минималистичный блокнот — внутри полноценные инструменты для командной работы. Функциональность здесь серьезная:
- Многопользовательский режим и совместная работа: Можно заводить отдельных пользователей и давать им доступ к «хранилищам» (vaults). Это выводит инструмент из категории «личный блокнот» в категорию «командная база знаний».
- OAuth-авторизация: Поддерживается вход через GitHub, Google, Keycloak и другие популярные сервисы.
- Продвинутый редактор: Markdown + визуальный интерфейс (WYSIWYG), со сплит-панелью предпросмотра. Есть шаблоны, теги, поиск по обратным ссылкам, автосохранение.
- Быстрый поиск: Используется typesense для быстрого и отказоустойчивого поиска по заметкам. Но это отдельный сервис, его тоже нужно поднять.
- PWA (Progressive Web App): Приложение можно установить на рабочий стол или смартфон для более удобного доступа.
Полезные ссылки:
➡️ Репозиторий на GitHub: brufdev/many-notes
➡️ Обсуждение на Reddit: Тред в /r/selfhosted
А вы чем пользуетесь для ведения заметок? Предпочитаете облачные сервисы или self-hosted решения? Делитесь в комментариях.
https://codeitdir.ru?utm_source=Telegram&utm_medium=social&utm_campaign=25968122
#РазборПродукта_КИД
Наткнулся на Reddit на небольшой, но очень интересный проект для тех, кто любит полный контроль над своими данными и ценит минимализм. Это self-hosted приложение для заметок Many-Notes.
TL;DR: Коротко о главном
💡 Что это? Опенсорсное web-приложение для работы с Markdown-записями, спроектированное с акцентом на минимализм и полный контроль над данными. Вы разворачиваете его у себя (self-hosted).
✅ Главная фишка: Использует базу данных (SQLite по умолчанию, но поддерживается MariaDB, MySQL и PostgreSQL) для продвинутых функций вроде многопользовательности и быстрого поиска, но при этом все заметки физически лежат в виде .md файлов. База нужна не для хранения текста заметок, а для метаданных, пользователей и индексации поиска.
🚀 Технологии: Написано на PHP, рассчитано на простую установку через Docker.
🤔 Кому зайдет? Небольшим командам или продвинутым пользователям, которым нужна своя база знаний с совместной работой, но без привязки к конкретному сервису.
Что под капотом? Ключевые возможности:
- Это не просто минималистичный блокнот — внутри полноценные инструменты для командной работы. Функциональность здесь серьезная:
- Многопользовательский режим и совместная работа: Можно заводить отдельных пользователей и давать им доступ к «хранилищам» (vaults). Это выводит инструмент из категории «личный блокнот» в категорию «командная база знаний».
- OAuth-авторизация: Поддерживается вход через GitHub, Google, Keycloak и другие популярные сервисы.
- Продвинутый редактор: Markdown + визуальный интерфейс (WYSIWYG), со сплит-панелью предпросмотра. Есть шаблоны, теги, поиск по обратным ссылкам, автосохранение.
- Быстрый поиск: Используется typesense для быстрого и отказоустойчивого поиска по заметкам. Но это отдельный сервис, его тоже нужно поднять.
- PWA (Progressive Web App): Приложение можно установить на рабочий стол или смартфон для более удобного доступа.
Полезные ссылки:
➡️ Репозиторий на GitHub: brufdev/many-notes
➡️ Обсуждение на Reddit: Тред в /r/selfhosted
А вы чем пользуетесь для ведения заметок? Предпочитаете облачные сервисы или self-hosted решения? Делитесь в комментариях.
https://codeitdir.ru?utm_source=Telegram&utm_medium=social&utm_campaign=25968122
#РазборПродукта_КИД
GitHub
GitHub - brufdev/many-notes: Markdown note-taking web application designed for simplicity
Markdown note-taking web application designed for simplicity - brufdev/many-notes
🔥 Новый практический выпуск: Собираем робота, который экономит мне час в день на чтении IT-новостей.
Постоянно тратил много времени на чтение ИТ-новостей. Дело нужное, но трудозатратное. Тем более, попадается часто многое, что мне не интересно. Надоело.
В итоге собрал себе робота-ассистента на n8n и GPT-4, который делает эту работу за меня. Теперь каждое утро получаю готовую выжимку самого полезного прямо в Telegram. Сэкономленный час времени — это серьезно.
Записал подробное видео, где показал весь процесс от А до Я. Внутри — пошаговая инструкция и готовый workflow, который можно забрать с GitHub и настроить под свои интересы. Это инструмент, который реально меняет рутину.
🎞 Смотреть на VK
📹 Смотреть на RuTube
📺 Смотреть на YouTube
🌍 Смотреть на Dzen
Весь код и промпт для AI, как всегда, выложил в открытый доступ: https://github.com/Diversus23/n8n-lib
Постоянно тратил много времени на чтение ИТ-новостей. Дело нужное, но трудозатратное. Тем более, попадается часто многое, что мне не интересно. Надоело.
В итоге собрал себе робота-ассистента на n8n и GPT-4, который делает эту работу за меня. Теперь каждое утро получаю готовую выжимку самого полезного прямо в Telegram. Сэкономленный час времени — это серьезно.
Записал подробное видео, где показал весь процесс от А до Я. Внутри — пошаговая инструкция и готовый workflow, который можно забрать с GitHub и настроить под свои интересы. Это инструмент, который реально меняет рутину.
Весь код и промпт для AI, как всегда, выложил в открытый доступ: https://github.com/Diversus23/n8n-lib
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👎1🔥1
«Ты что, мне не веришь?» — как выходить из ловушек в диалоге с руководителем
Есть старая уловка: инспектор ДПС останавливает вас, говорит, что вы нарушили. Вы уверены, что нет, и начинаете спорить. В ответ он задаёт вопрос: «То есть ты мне не веришь?»
Разговор сразу уходит с уровня фактов на уровень отношений и статуса. И дальше спорить почти невозможно.
В работе подчинённого с руководителем происходят такие же истории. Вроде бы вы обсуждаете проект или задачу, но вдруг разговор сворачивает в сторону доверия, компетентности или приоритетов. Это ловушки, и важно уметь из них выходить.
Ловушка 1. «Ты хочешь сказать, я не разбираюсь?»
Ситуация. Подчинённый предлагает более эффективный вариант. Руководитель переводит спор в плоскость «компетентности начальника».
Вы: Для нас нанять подрядчика будет дешевле, чем делать эти работы самостоятельно.
Руководитель: Ты хочешь сказать, что я в этом не разбираюсь и зря вообще предлагал свой вариант?
Как реагировать? Не спорить о компетенции, а подчеркнуть ценность данных.
Решение: Я уверен, что вы разбираетесь. Просто показываю расчёты и предлагаю сравнить варианты. Решать, конечно, вам.
Подмена: Спор о цифрах превращается в спор о компетентности.
Ловушка 2. «Ты не доверяешь моему слову?»
Ситуация. Руководитель передаёт информацию от партнёра или поставщика. Подчинённый проверяет и находит неточность.
Руководитель: Поставщик сказал, что эта система без проблем установится у нас.
Вы: Я проверил, и технически это не так. Потребуются дополнительные работы.
Руководитель: То есть ты не доверяешь моему слову и словам партнёра?
Как реагировать? Покажите, что проверка — не про доверие, а про снижение рисков. Решение: Я доверяю вам, поэтому и проверил слова поставщика. Вот, что показала проверка. Теперь можно обсудить риски и цену доработки.
Подмена: Вместо оценки фактов — вопрос личного доверия.
Ловушка 3. «Ты ставишь под сомнение мои приоритеты?»
Ситуация. Руководитель называет задачу «срочной», а подчинённый указывает на последствия для других проектов.
Руководитель: Срочно внедряем CRM, от этого зависит работа продаж.
Вы: Если мы начнём сейчас, есть риск сорвать плановую миграцию бухгалтерии.
Руководитель: То есть мои приоритеты ты считаешь неправильными?
Как реагировать? Признайте право начальника на приоритет, но верните его в поле выбора.
Решение: Приоритеты определяете вы. Моя задача — показать последствия. Если делаем А сейчас, то Б задержится на месяц.
Подмена: разговор о ресурсах превращается в разговор о «лояльности» к стратегическим целям.
Выводы
Все эти примеры сводятся к одному: разговор уходит из области фактов в плоскость статуса, доверия, авторитета. Если подчинённый начинает оправдываться или спорить в лоб, он проигрывает.
Гораздо эффективнее — спокойно вернуть диалог к данным и интересам бизнеса. Подчёркивайте, что финальное решение всегда за руководителем. Ваша задача — дать ему фактуру для выбора. В итоге вы не спорите с начальником, а помогаете ему принимать взвешенные решения.
Чек-лист: как выходить из провокационных ловушек
Что делать
✅ Спокойно возвращайте разговор в плоскость фактов и цифр.
✅ Подчёркивайте право руководителя на финальное решение.
✅ Формулируйте аргументы через заботу о бизнесе: «чтобы снизить риски», «чтобы не потерять сроки».
✅ Используйте переформулировки. Меняйте «Ты не доверяешь?» на «Я доверяю, поэтому проверил детали».
Чего не делать
❌ Не спорьте в лоб, не говорите «я прав, а вы не правы».
❌ Не оправдывайтесь. Фразы вроде «нет-нет, я вам верю, честно» ослабляют позицию.
❌ Не переводите разговор обратно в эмоции.
❌ Не теряйте фокус обсуждения. Цель — решение для бизнеса, а не выяснение отношений.
#Бизнес_КИД
Есть старая уловка: инспектор ДПС останавливает вас, говорит, что вы нарушили. Вы уверены, что нет, и начинаете спорить. В ответ он задаёт вопрос: «То есть ты мне не веришь?»
Разговор сразу уходит с уровня фактов на уровень отношений и статуса. И дальше спорить почти невозможно.
В работе подчинённого с руководителем происходят такие же истории. Вроде бы вы обсуждаете проект или задачу, но вдруг разговор сворачивает в сторону доверия, компетентности или приоритетов. Это ловушки, и важно уметь из них выходить.
Ловушка 1. «Ты хочешь сказать, я не разбираюсь?»
Ситуация. Подчинённый предлагает более эффективный вариант. Руководитель переводит спор в плоскость «компетентности начальника».
Вы: Для нас нанять подрядчика будет дешевле, чем делать эти работы самостоятельно.
Руководитель: Ты хочешь сказать, что я в этом не разбираюсь и зря вообще предлагал свой вариант?
Ловушка 2. «Ты не доверяешь моему слову?»
Ситуация. Руководитель передаёт информацию от партнёра или поставщика. Подчинённый проверяет и находит неточность.
Руководитель: Поставщик сказал, что эта система без проблем установится у нас.
Вы: Я проверил, и технически это не так. Потребуются дополнительные работы.
Руководитель: То есть ты не доверяешь моему слову и словам партнёра?
Подмена: Вместо оценки фактов — вопрос личного доверия.
Ловушка 3. «Ты ставишь под сомнение мои приоритеты?»
Ситуация. Руководитель называет задачу «срочной», а подчинённый указывает на последствия для других проектов.
Руководитель: Срочно внедряем CRM, от этого зависит работа продаж.
Вы: Если мы начнём сейчас, есть риск сорвать плановую миграцию бухгалтерии.
Руководитель: То есть мои приоритеты ты считаешь неправильными?
Выводы
Все эти примеры сводятся к одному: разговор уходит из области фактов в плоскость статуса, доверия, авторитета. Если подчинённый начинает оправдываться или спорить в лоб, он проигрывает.
Гораздо эффективнее — спокойно вернуть диалог к данным и интересам бизнеса. Подчёркивайте, что финальное решение всегда за руководителем. Ваша задача — дать ему фактуру для выбора. В итоге вы не спорите с начальником, а помогаете ему принимать взвешенные решения.
Чек-лист: как выходить из провокационных ловушек
Что делать
✅ Спокойно возвращайте разговор в плоскость фактов и цифр.
✅ Подчёркивайте право руководителя на финальное решение.
✅ Формулируйте аргументы через заботу о бизнесе: «чтобы снизить риски», «чтобы не потерять сроки».
✅ Используйте переформулировки. Меняйте «Ты не доверяешь?» на «Я доверяю, поэтому проверил детали».
Чего не делать
❌ Не спорьте в лоб, не говорите «я прав, а вы не правы».
❌ Не оправдывайтесь. Фразы вроде «нет-нет, я вам верю, честно» ослабляют позицию.
❌ Не переводите разговор обратно в эмоции.
❌ Не теряйте фокус обсуждения. Цель — решение для бизнеса, а не выяснение отношений.
#Бизнес_КИД
🔥3🍌1
Как понять, какие AI-модели действительно работают? Используем openrouter.ai
Если вы не хотите «читать в новостях хайп», а видеть реальную статистику по тому, какие AI-модели сейчас используют разработчики и компании — рекомендую заглянуть на https://openrouter.ai/rankings?view=trending
Что это?
- По сути, универсальный роутер для нейросетей. Можно в режиме чата попробовать практически любую популярную модель (GPT-5, Claude, Gemini, LLaMA и т.п.);
- В открытом доступе есть статистика использования каждой модели — видно, что реально востребовано, а что лежит мёртвым грузом;
- Дополнительно можно подсмотреть, какие инструменты и интеграции сейчас «в ходу» — многие сервисы и плагины работают именно через OpenRouter.
- Есть бесплатные модели, которые тоже можно попробовать.
Зачем это?
- Любому человеку, кто интересуется темой AI будет полезно, какие технологии стоит рассматривать для пилотов и прототипов, а какие пока «сырые»;
- Можно сравнить отклик разных моделей под свои задачи (от техподдержки до генерации кода) без сложной инфраструктуры;
- Это объективный индикатор «пика популярности» моделей, а не просто маркетинговые пресс-релизы от вендоров.
Например, вы можете зайти в их чат, выбрать из списка Claude 4 Sonnet и Grok 4, задать им одну и ту же задачу по генерации SQL-запроса и сравнить скорость, точность и стиль ответа.
На скриншоте, отображено какие инструменты используют OpenRouter и в каком объеме. Это, кстати, позволяет узнать в том числе и о новых инструментах.
Минусы
Но есть и один серьезный минус: полноценно попробовать можно только используя карту иностранного банка. С другой стороны, чтобы посмотреть статистику и понять что вообще происходит, денег не нужно.
Также статистика OpenRouter показывает популярность моделей только в рамках своей платформы. Это важный, но не исчерпывающий срез рынка. Крупные компании могут использовать API напрямую от OpenAI, Anthropic или Google, и этот трафик в статистике OpenRouter не отражается. Статистика — это индикатор, но не абсолютная истина. Тем не менее, она показывает тренды.
Если вы не хотите «читать в новостях хайп», а видеть реальную статистику по тому, какие AI-модели сейчас используют разработчики и компании — рекомендую заглянуть на https://openrouter.ai/rankings?view=trending
Что это?
- По сути, универсальный роутер для нейросетей. Можно в режиме чата попробовать практически любую популярную модель (GPT-5, Claude, Gemini, LLaMA и т.п.);
- В открытом доступе есть статистика использования каждой модели — видно, что реально востребовано, а что лежит мёртвым грузом;
- Дополнительно можно подсмотреть, какие инструменты и интеграции сейчас «в ходу» — многие сервисы и плагины работают именно через OpenRouter.
- Есть бесплатные модели, которые тоже можно попробовать.
Зачем это?
- Любому человеку, кто интересуется темой AI будет полезно, какие технологии стоит рассматривать для пилотов и прототипов, а какие пока «сырые»;
- Можно сравнить отклик разных моделей под свои задачи (от техподдержки до генерации кода) без сложной инфраструктуры;
- Это объективный индикатор «пика популярности» моделей, а не просто маркетинговые пресс-релизы от вендоров.
Например, вы можете зайти в их чат, выбрать из списка Claude 4 Sonnet и Grok 4, задать им одну и ту же задачу по генерации SQL-запроса и сравнить скорость, точность и стиль ответа.
На скриншоте, отображено какие инструменты используют OpenRouter и в каком объеме. Это, кстати, позволяет узнать в том числе и о новых инструментах.
Минусы
Но есть и один серьезный минус: полноценно попробовать можно только используя карту иностранного банка. С другой стороны, чтобы посмотреть статистику и понять что вообще происходит, денег не нужно.
Также статистика OpenRouter показывает популярность моделей только в рамках своей платформы. Это важный, но не исчерпывающий срез рынка. Крупные компании могут использовать API напрямую от OpenAI, Anthropic или Google, и этот трафик в статистике OpenRouter не отражается. Статистика — это индикатор, но не абсолютная истина. Тем не менее, она показывает тренды.
🤣1
Мы искали React-разработчика и никого не нашли. Почему вы тоже не можете найти работу.
Недавно искали себе в команду помощника фронтенд-разработчика. На React. Разместили вакансию на hh, и тут началось. Мы просто утонули в откликах от людей без нужного опыта, а те, кто нам подходил, видимо, затерялись в этой массе. В общем, эпопея закончилась ничем, мы никого не взяли.
И это не просто наша частная история, а диагноз всему IT-рынку. Сегодня на Хабре вышла статья Кати Булановой, которая по сути подтвердила мои мысли цифрами.
https://habr.com/ru/articles/941304?utm_source=Telegram&utm_medium=social&utm_campaign=26064343
Если коротко, вот что на самом деле происходит.
1. Рынок кандидата сменился на рынок работодателя.
Время, когда разработчик мог выбирать среди нескольких офферов, прошло. Теперь выбирает компания. Люди это поняли и затаились. Фразы вроде «я выгорел и ушел в никуда» слышны все реже. Все держатся за стабильность, потому что есть реальный шанс уйти и потом вообще не найти работу.
2. Фильтр на входе стал жестче.
Легких офферов больше нет. Компании смотрят на каждого кандидата под лупой, потому что цена ошибки выросла. Плюс появились те, кто хорошо проходят собеседования благодаря нейросетям (когда на втором экране есть помощник, который работает по голосу, а когда кандидат смотрит в сторону нейросеть исправляет его глаза и не видно, что он смотрит не туда. Возьмешь вот так человека, а он ничего не знает. Страшновато.
3. «Вкатуны» создали шум, в котором тонут все.
Рынок завалили выпускники курсов. Народ хочет больших зарплат, но часто нет ни опыта, ни даже базовых знаний. И получается замкнутый круг. Работодатель тратит кучу времени, разбирая сотни пустых резюме. Новичок получает отказ за отказом, потому что он один из тысячи таких же. А толковый, опытный специалист просто теряется в этой лавине откликов. Его резюме может быть 150-м по счету, и до него руки просто не доходят. В итоге плохо всем.
Какой из этого выход?
Опытным ребятам, которые сейчас в поиске, я могу посоветовать одно: хватит быть просто строчкой в общем списке. Общайтесь в сообществах, пишите напрямую тимлидам, показывайте свой код на GitHub. Ваша главная задача сегодня, это пробиться через весь этот информационный шум. Иначе вас просто не увидят.
#Кейсы_КИД
Недавно искали себе в команду помощника фронтенд-разработчика. На React. Разместили вакансию на hh, и тут началось. Мы просто утонули в откликах от людей без нужного опыта, а те, кто нам подходил, видимо, затерялись в этой массе. В общем, эпопея закончилась ничем, мы никого не взяли.
И это не просто наша частная история, а диагноз всему IT-рынку. Сегодня на Хабре вышла статья Кати Булановой, которая по сути подтвердила мои мысли цифрами.
https://habr.com/ru/articles/941304?utm_source=Telegram&utm_medium=social&utm_campaign=26064343
Если коротко, вот что на самом деле происходит.
1. Рынок кандидата сменился на рынок работодателя.
Время, когда разработчик мог выбирать среди нескольких офферов, прошло. Теперь выбирает компания. Люди это поняли и затаились. Фразы вроде «я выгорел и ушел в никуда» слышны все реже. Все держатся за стабильность, потому что есть реальный шанс уйти и потом вообще не найти работу.
2. Фильтр на входе стал жестче.
Легких офферов больше нет. Компании смотрят на каждого кандидата под лупой, потому что цена ошибки выросла. Плюс появились те, кто хорошо проходят собеседования благодаря нейросетям (когда на втором экране есть помощник, который работает по голосу, а когда кандидат смотрит в сторону нейросеть исправляет его глаза и не видно, что он смотрит не туда. Возьмешь вот так человека, а он ничего не знает. Страшновато.
3. «Вкатуны» создали шум, в котором тонут все.
Рынок завалили выпускники курсов. Народ хочет больших зарплат, но часто нет ни опыта, ни даже базовых знаний. И получается замкнутый круг. Работодатель тратит кучу времени, разбирая сотни пустых резюме. Новичок получает отказ за отказом, потому что он один из тысячи таких же. А толковый, опытный специалист просто теряется в этой лавине откликов. Его резюме может быть 150-м по счету, и до него руки просто не доходят. В итоге плохо всем.
Какой из этого выход?
Опытным ребятам, которые сейчас в поиске, я могу посоветовать одно: хватит быть просто строчкой в общем списке. Общайтесь в сообществах, пишите напрямую тимлидам, показывайте свой код на GitHub. Ваша главная задача сегодня, это пробиться через весь этот информационный шум. Иначе вас просто не увидят.
#Кейсы_КИД
Хабр
Парадокс IT-рынка 2025: почему ИТ-шники не могут найти работу, а компании – сотрудников
Привет, Хабр! 👋 Меня зовут Катя, я уже 15 лет занимаюсь IT-рекрутингом: начинала в консалтинге, последние 10 лет работаю с европейским рынком. Сейчас рынок труда в IT стал настолько турбулентным, что...
🔥2
Не каждый разработчик мечтает стать руководителем. И это нормально.
У меня есть старый друг Семён. Он толковый разработчик и работает в одном из крупнейших финтехов страны с основным стеком Java. Большой финтех, море возможностей, и логично было бы предположить, что он давно метит в тимлиды или руководителем отдела. Мы как-то разговорились об этом.
Ответ меня не то чтобы удивил, но заставил в очередной раз задуматься. Семён спокойно сказал: «Виталик, мне это не нужно. Я люблю писать код, решать сложные задачи. Мне не нужны вот эти вот созвоны, бюджеты, отчеты и чужие проблемы. Да, зарплата ниже. Зато нервы целее, и я занимаюсь тем, что мне действительно нравится».
И ведь он абсолютно прав. В IT-сфере почему-то принято считать, что единственный путь развития для хорошего специалиста — это вертикальный рост в менеджмент. Если ты крутой спец и не хочешь становиться руководителем, на тебя смотрят с подозрением. Словно ты без амбиций или просто ленивый.
Это опасное заблуждение.
Самая частая и дорогая ошибка в бизнесе — сделать из лучшего инженера худшего менеджера. Компания теряет сильного технического специалиста и приобретает слабого, выгоревшего управленца, который страдает сам и мучает команду.
Кодить и управлять людьми — это две разные профессии. Хороший руководитель — это не тот, кто пишет самый изящный код. Это тот, кто:
Берет на себя ответственность. Не ищет виноватых, а ищет решение.
Умеет говорить с людьми. Может и задачу поставить, и конфликт разрулить, и просто услышать человека.
Создает климат в коллективе. Понимает, что токсичная атмосфера убивает продуктивность быстрее, чем любая техническая проблема.
Это отдельный, сложный набор навыков. И он никак не связан с умением виртуозно настраивать CI/CD или оптимизировать запросы к базе данных.
Поэтому, прежде чем гнаться за должностью тимлида или начальника отдела, просто честно спросите себя: «А мне это точно надо?». Может, ваш путь — это горизонтальное развитие? Стать незаменимым экспертом в своей области, менторить новичков, заниматься самыми сложными проектами. Это не менее достойный и уважаемый путь.
Интересно, а как у вас в компаниях? Сталкивались с ситуацией, когда отличного спеца «повышали» до плохого менеджера? Или, может, вы сами сделали такой же осознанный выбор, как мой товарищ?
Код ИТ-директора
#Истории_КИД
У меня есть старый друг Семён. Он толковый разработчик и работает в одном из крупнейших финтехов страны с основным стеком Java. Большой финтех, море возможностей, и логично было бы предположить, что он давно метит в тимлиды или руководителем отдела. Мы как-то разговорились об этом.
Ответ меня не то чтобы удивил, но заставил в очередной раз задуматься. Семён спокойно сказал: «Виталик, мне это не нужно. Я люблю писать код, решать сложные задачи. Мне не нужны вот эти вот созвоны, бюджеты, отчеты и чужие проблемы. Да, зарплата ниже. Зато нервы целее, и я занимаюсь тем, что мне действительно нравится».
И ведь он абсолютно прав. В IT-сфере почему-то принято считать, что единственный путь развития для хорошего специалиста — это вертикальный рост в менеджмент. Если ты крутой спец и не хочешь становиться руководителем, на тебя смотрят с подозрением. Словно ты без амбиций или просто ленивый.
Это опасное заблуждение.
Самая частая и дорогая ошибка в бизнесе — сделать из лучшего инженера худшего менеджера. Компания теряет сильного технического специалиста и приобретает слабого, выгоревшего управленца, который страдает сам и мучает команду.
Кодить и управлять людьми — это две разные профессии. Хороший руководитель — это не тот, кто пишет самый изящный код. Это тот, кто:
Берет на себя ответственность. Не ищет виноватых, а ищет решение.
Умеет говорить с людьми. Может и задачу поставить, и конфликт разрулить, и просто услышать человека.
Создает климат в коллективе. Понимает, что токсичная атмосфера убивает продуктивность быстрее, чем любая техническая проблема.
Это отдельный, сложный набор навыков. И он никак не связан с умением виртуозно настраивать CI/CD или оптимизировать запросы к базе данных.
Поэтому, прежде чем гнаться за должностью тимлида или начальника отдела, просто честно спросите себя: «А мне это точно надо?». Может, ваш путь — это горизонтальное развитие? Стать незаменимым экспертом в своей области, менторить новичков, заниматься самыми сложными проектами. Это не менее достойный и уважаемый путь.
Интересно, а как у вас в компаниях? Сталкивались с ситуацией, когда отличного спеца «повышали» до плохого менеджера? Или, может, вы сами сделали такой же осознанный выбор, как мой товарищ?
Код ИТ-директора
#Истории_КИД
❤2👍1🔥1👏1🌭1