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
Нашел интересный сервис энтузиаста-разработчика, который создал сервис для обработки фото. В частности поддерживается создание цветных фотографий из черно-белых, реставрация старых фотоснимков, удаление фона, улучшение качества фотографий (апскейл). Но я бы не приводил этот сервис, если бы не одно НО: сервис абсолютно БЕСПЛАТНЫЙ.
Пользуйтесь: https://photomagics.ru?utm_source=Telegram&utm_medium=social&utm_campaign=26088681
Код ИТ-директора
Пользуйтесь: https://photomagics.ru?utm_source=Telegram&utm_medium=social&utm_campaign=26088681
Код ИТ-директора
👍1🤬1
История про Вову и необжатые коннекторы за которые отвечал я
Иногда одна короткая история из прошлого говорит об ответственности больше, чем толстая книга по управлению. Недавно как раз вспомнил один случай из далекого 2007 года, который отлично иллюстрирует, почему некоторые специалисты навсегда остаются просто исполнителями с которыми никто не хочет работать.
История одного факапа
В тот момент я работал в компании, которая обслуживала клиентов по 1С. Один из них, бюджетная организация, попросил нас вдобавок к основной работе подключить к локальной сети пару компьютеров. Не наш основной профиль, но директор решила, что это не проблема. В штате как раз был админ, назовем его Вова.
У нас в компании тогда даже ходила шутка и директор говорила что однажды его выпорет. Шутка, конечно. Но поводы для неё были совсем не смешные.
И вот мы с Вовой едем к клиенту за 50 км от города. Он тянет сеть, я занимаюсь 1С. Вечером уезжаем, вроде все довольны. Я в его часть работы особо не вникал, и, как оказалось, зря.
На следующей неделе я снова приезжаю к ним. Идем с бухом клиента в другой кабинет и прямо на моих глазах бухгалтер, милая женщина, зацепилась ногами за провода на полу и чуть не упала. Я смотрю, а у них по всему этому кабинету лежат кабели, ничем не закрепленные. Просто скопом лежат на проходе в перемешку.
Спрашиваю: «Что же у вас провода на полу валяются? Так ведь и убиться недолго». А она мне отвечает: «Так это же ваша фирма на той неделе сеть тянула к этому кабинету. Кстати, эти два компьютера так и не подключили к сети, но зато теперь тут везде провода».
И тут меня, что называется, бомбануло. 🔥
Претензию за чужую работу выслушиваю я. Начинаю распутывать этот клубок и вижу апогей картины: на полу лежит пару кабелей, причем размера больше чем нужна, а на конце этих проводов просто голые жилы. Провод даже не обжат. Вроде бы всего два кабеля, но ощущение что их больше.
Вернувшись в офис, я рассказал всё директору. Она в очередной раз пообещала Вове ремень, а меня попросила проконтролировать, чтобы он всё доделал.
Я пошёл к Вове с одним вопросом: «Почему?» Ответ был гениален в своей простоте: «А я коннекторы забыл».
То есть, человек приехал за 50 км, протянул провод, понял, что обжать его нечем, и решил, что лучший выход — это просто всё бросить и молча уехать. Ни слова не сказав ни клиенту, ни мне, ни директору. Он просто сделал вид, что работа выполнена.
Естественно, мы поехали снова. Я, хоть это и не мой профиль, помогал ему всё доделывать, потому что смотреть на эту бухгалтершу было жалко. Под моим контролем он всё закрепил к стене, обжал и все подключил.
Почему это не просто косяк, а диагноз
Таких «Вов» на самом деле полно. Сейчас модно кивать на зумеров, которые могут договориться о выходе на работу и просто не прийти. Но эта история, напомню, из 2007-го. Тогда зумеры только рождались. Так что проблема не в поколении. Проблема в ответственности.
Я до сих пор не понимаю мотивы таких людей.
• Сделать и бросить. Протянуть кабель, закрепить его в кабель-канал и обжать — это не сверхзадача. Это рутина.
• Солгать молчанием. Ну забыл ты коннекторы, бывает. Подойди к клиенту, извинись, скажи: «Мой косяк, не взял инструмент, приеду завтра и всё доделаю за час». Клиент бы понял. Но вместо этого он выбрал трусливое молчание, подставив и меня, и репутацию компании.
Такое поведение — маркер, который проявляется не только в работе. Уверен, что и в личной жизни у таких людей всё строится по тому же принципу: избежать ответственности, сделать вид, что проблемы не существует, и надеяться, что «само рассосётся».
Вывод: «Вова» — это бомба замедленного действия для бизнеса
В конце поста логично встают два вопроса: нужны ли такие «Вовы» компании и что с ними делать?
Мой ответ: категорически не нужны. И дело здесь не в морали, а в чистой математике и управлении рисками.
Давайте просто посчитаем ущерб от забытых коннекторов:
Иногда одна короткая история из прошлого говорит об ответственности больше, чем толстая книга по управлению. Недавно как раз вспомнил один случай из далекого 2007 года, который отлично иллюстрирует, почему некоторые специалисты навсегда остаются просто исполнителями с которыми никто не хочет работать.
История одного факапа
В тот момент я работал в компании, которая обслуживала клиентов по 1С. Один из них, бюджетная организация, попросил нас вдобавок к основной работе подключить к локальной сети пару компьютеров. Не наш основной профиль, но директор решила, что это не проблема. В штате как раз был админ, назовем его Вова.
У нас в компании тогда даже ходила шутка и директор говорила что однажды его выпорет. Шутка, конечно. Но поводы для неё были совсем не смешные.
И вот мы с Вовой едем к клиенту за 50 км от города. Он тянет сеть, я занимаюсь 1С. Вечером уезжаем, вроде все довольны. Я в его часть работы особо не вникал, и, как оказалось, зря.
На следующей неделе я снова приезжаю к ним. Идем с бухом клиента в другой кабинет и прямо на моих глазах бухгалтер, милая женщина, зацепилась ногами за провода на полу и чуть не упала. Я смотрю, а у них по всему этому кабинету лежат кабели, ничем не закрепленные. Просто скопом лежат на проходе в перемешку.
Спрашиваю: «Что же у вас провода на полу валяются? Так ведь и убиться недолго». А она мне отвечает: «Так это же ваша фирма на той неделе сеть тянула к этому кабинету. Кстати, эти два компьютера так и не подключили к сети, но зато теперь тут везде провода».
И тут меня, что называется, бомбануло. 🔥
Претензию за чужую работу выслушиваю я. Начинаю распутывать этот клубок и вижу апогей картины: на полу лежит пару кабелей, причем размера больше чем нужна, а на конце этих проводов просто голые жилы. Провод даже не обжат. Вроде бы всего два кабеля, но ощущение что их больше.
Вернувшись в офис, я рассказал всё директору. Она в очередной раз пообещала Вове ремень, а меня попросила проконтролировать, чтобы он всё доделал.
Я пошёл к Вове с одним вопросом: «Почему?» Ответ был гениален в своей простоте: «А я коннекторы забыл».
То есть, человек приехал за 50 км, протянул провод, понял, что обжать его нечем, и решил, что лучший выход — это просто всё бросить и молча уехать. Ни слова не сказав ни клиенту, ни мне, ни директору. Он просто сделал вид, что работа выполнена.
Естественно, мы поехали снова. Я, хоть это и не мой профиль, помогал ему всё доделывать, потому что смотреть на эту бухгалтершу было жалко. Под моим контролем он всё закрепил к стене, обжал и все подключил.
Почему это не просто косяк, а диагноз
Таких «Вов» на самом деле полно. Сейчас модно кивать на зумеров, которые могут договориться о выходе на работу и просто не прийти. Но эта история, напомню, из 2007-го. Тогда зумеры только рождались. Так что проблема не в поколении. Проблема в ответственности.
Я до сих пор не понимаю мотивы таких людей.
• Сделать и бросить. Протянуть кабель, закрепить его в кабель-канал и обжать — это не сверхзадача. Это рутина.
• Солгать молчанием. Ну забыл ты коннекторы, бывает. Подойди к клиенту, извинись, скажи: «Мой косяк, не взял инструмент, приеду завтра и всё доделаю за час». Клиент бы понял. Но вместо этого он выбрал трусливое молчание, подставив и меня, и репутацию компании.
Такое поведение — маркер, который проявляется не только в работе. Уверен, что и в личной жизни у таких людей всё строится по тому же принципу: избежать ответственности, сделать вид, что проблемы не существует, и надеяться, что «само рассосётся».
Вывод: «Вова» — это бомба замедленного действия для бизнеса
В конце поста логично встают два вопроса: нужны ли такие «Вовы» компании и что с ними делать?
Мой ответ: категорически не нужны. И дело здесь не в морали, а в чистой математике и управлении рисками.
Давайте просто посчитаем ущерб от забытых коннекторов:
• Две поездки вместо одной (+100 км).
• Моё время, потраченное на выяснение и контроль.
• Его время, потраченное на повторную работу.
• Самое главное — удар по лояльности клиента, который столкнулся с бардаком и неработающим решением.
Финансовые потери это мелочь против главного ущерба от «Вовы». А главный ущерб - это создание непредсказуемости.
Ответственный сотрудник может ошибиться. Он может даже сжечь сервер. Но он тут же придёт и скажет: «Я накосячил. Вот здесь. План действий такой». Его ошибка — это управляемый процесс. Вы знаете о проблеме и можете на неё реагировать.
«Вова» — это неуправляемый хаос. Он молчит. Он создаёт в ваших бизнес-процессах чёрные дыры, о существовании которых вы узнаете, только когда туда свалится клиент или проект. Такой сотрудник — это ходячий баг в вашей системе управления. Вы никогда не знаете, что у него на самом деле сделано, а что «сделано на словах».
Именно поэтому ошибка простительна, а трусливое молчание — нет. Ошибка — это рабочий момент. Молчание — это саботаж, осознанный или нет.
Привычка доводить дело до конца и не подставлять команду это фундамент, без которого любой опыт и знания бесполезны.
А вы встречались с такими «Вовами» и что, на ваш взгляд, страшнее: сделать ошибку и признаться, или молча уйти в закат и никому ничего не сказать?
• Моё время, потраченное на выяснение и контроль.
• Его время, потраченное на повторную работу.
• Самое главное — удар по лояльности клиента, который столкнулся с бардаком и неработающим решением.
Финансовые потери это мелочь против главного ущерба от «Вовы». А главный ущерб - это создание непредсказуемости.
Ответственный сотрудник может ошибиться. Он может даже сжечь сервер. Но он тут же придёт и скажет: «Я накосячил. Вот здесь. План действий такой». Его ошибка — это управляемый процесс. Вы знаете о проблеме и можете на неё реагировать.
«Вова» — это неуправляемый хаос. Он молчит. Он создаёт в ваших бизнес-процессах чёрные дыры, о существовании которых вы узнаете, только когда туда свалится клиент или проект. Такой сотрудник — это ходячий баг в вашей системе управления. Вы никогда не знаете, что у него на самом деле сделано, а что «сделано на словах».
Именно поэтому ошибка простительна, а трусливое молчание — нет. Ошибка — это рабочий момент. Молчание — это саботаж, осознанный или нет.
Привычка доводить дело до конца и не подставлять команду это фундамент, без которого любой опыт и знания бесполезны.
А вы встречались с такими «Вовами» и что, на ваш взгляд, страшнее: сделать ошибку и признаться, или молча уйти в закат и никому ничего не сказать?
🔥1
Автоматическая сборка PDF-документации из Markdown в GitLab CI
Готовили релиз нашего нового решения для 1С по отправке СМС-подтверждений и столкнулись с классической задачей. Документацию мы ведем в Markdown. Это удобно для нас, но не для конечного клиента.
Клиенту нужен привычный PDF. Простой и надежный.
Главный вопрос: как автоматически собирать несколько
Решение нашлось в связке Docker и Pandoc. Вот пошаговый план:
Основа: Берем готовый Docker-образ с Pandoc.
Подготовка: Внутрь контейнера копируем нашу папку
Сборка: Запускаем Pandoc, который конвертирует все файлы в единый PDF.
Выгрузка: Копируем готовый PDF из контейнера и сохраняем его как артефакт в GitLab.
Подход универсален, неважно, где запущен Docker. Вся логика инкапсулирована в контейнере.
Подробно описал как все это настроить в Gitlab CI и выложи ссылки на github 👉 здесь
Получилось неплохо
Готовили релиз нашего нового решения для 1С по отправке СМС-подтверждений и столкнулись с классической задачей. Документацию мы ведем в Markdown. Это удобно для нас, но не для конечного клиента.
Клиенту нужен привычный PDF. Простой и надежный.
Главный вопрос: как автоматически собирать несколько
.md файлов с картинками в один PDF-файл прямо в пайплайне GitLab CI? Особенно когда твои раннеры работают на PowerShell под Windows, как у нас.Решение нашлось в связке Docker и Pandoc. Вот пошаговый план:
Основа: Берем готовый Docker-образ с Pandoc.
Подготовка: Внутрь контейнера копируем нашу папку
docs с Markdown-файлами.Сборка: Запускаем Pandoc, который конвертирует все файлы в единый PDF.
Выгрузка: Копируем готовый PDF из контейнера и сохраняем его как артефакт в GitLab.
Подход универсален, неважно, где запущен Docker. Вся логика инкапсулирована в контейнере.
Подробно описал как все это настроить в Gitlab CI и выложи ссылки на github 👉 здесь
Получилось неплохо
softonit.ru
Подтверждение дисконтной карты по SMS в 1С
Каталог программ и услуг
🔥2
Про любимый браузер
До сих пор не понимаю людей, которые используют Google Chrome или Edge. Понятно, что это вопрос холивара, какой инструмент лучше или хуже — большой вопрос.
Лично я использую Яндекс Браузер и уже очень давно. Самое главное, что меня подкупило — это кнопка с озвучкой на русском языке в YouTube :)
Часто смотрю зарубежные каналы и мне этого очень не хватало.
Ну круто же!
Еще тоже фича, когда смотришь видео на вкладке и переключаешься на другую вкладку в браузере, видео выносится в другое маленькое окошко и можно продолжать его смотреть.
Что есть такого в Chrome, что нужно использовать его? В Яндекс Браузере есть всё что в Chrome, и даже больше. Расширения ставятся такие же как и в Хром, а еще есть нейроредактор, который позволяет быстро править тексты, есть пересказ на каждой странице в браузере, есть возможность использовать Яндекс Музыку прямо в браузере. Просто нажал и тебе всё пересказал браузер кратко или не очень.
Ставьте себе Яндекс Браузер и пользуйтесь.
До сих пор не понимаю людей, которые используют Google Chrome или Edge. Понятно, что это вопрос холивара, какой инструмент лучше или хуже — большой вопрос.
Лично я использую Яндекс Браузер и уже очень давно. Самое главное, что меня подкупило — это кнопка с озвучкой на русском языке в YouTube :)
Часто смотрю зарубежные каналы и мне этого очень не хватало.
Ну круто же!
Еще тоже фича, когда смотришь видео на вкладке и переключаешься на другую вкладку в браузере, видео выносится в другое маленькое окошко и можно продолжать его смотреть.
Что есть такого в Chrome, что нужно использовать его? В Яндекс Браузере есть всё что в Chrome, и даже больше. Расширения ставятся такие же как и в Хром, а еще есть нейроредактор, который позволяет быстро править тексты, есть пересказ на каждой странице в браузере, есть возможность использовать Яндекс Музыку прямо в браузере. Просто нажал и тебе всё пересказал браузер кратко или не очень.
Ставьте себе Яндекс Браузер и пользуйтесь.
🔥1🤔1💩1🤝1
Две больших коллекции бесплатных SVG-иконок
В мобильном приложении сейчас активно используем библиотеку SVG-иконок Lucide (лицензия ISC License — похожа на MIT):
https://lucide.dev/icons/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Можно задать размер, толщину и цвет.
Еще, мне нравится коллекция Heroicons (MIT License):
https://heroicons.com/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Она поменьше, но иконки тоже неплохие. Эту коллекцию используем на сайте Софтонит.
Сохраняйте, чтобы не забыть.
Код ИТ-директора
В мобильном приложении сейчас активно используем библиотеку SVG-иконок Lucide (лицензия ISC License — похожа на MIT):
https://lucide.dev/icons/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Можно задать размер, толщину и цвет.
Еще, мне нравится коллекция Heroicons (MIT License):
https://heroicons.com/?utm_source=Telegram&utm_medium=social&utm_campaign=26209753
Она поменьше, но иконки тоже неплохие. Эту коллекцию используем на сайте Софтонит.
Сохраняйте, чтобы не забыть.
Код ИТ-директора
Lucide
Lucide Icons
Beautiful & consistent icon toolkit made by the community.
👍1🔥1