Резюме с бесконечной чередой работ: красный флаг или новое поколение?

Меня каждый раз удивляют резюме на hh.ru, где у соискателя — 7 мест работы за последние 2 года. Каждое по 3–4 месяца (!) Что это вообще?

Я понимаю, что можно уйти от токсичного начальника. Один-два раза. Но если человек регулярно сбегает с места — у меня два варианта объяснения:

1. Он не тянет. На собеседовании выглядит норм, но по факту быстро становится балластом. Его увольняют — он ищет новую «жертву».
2. Он не умеет работать в команде. Или просто не знает, чего хочет. То стартап не такой, то проект скучный, то команда «не зашла».

В любом случае — это рисковый кандидат. Особенно в небольших ИТ-компаниях, где каждый человек на счету. Инвестировать время в такого — себе дороже.

Да, бывают исключения. Но скорее всего все так как я описал. Что думаете на эту тему?

AI — это бригада строителей, за которой нужен глаз да глаз

Весь мир гудит про AI. Я решил проверить его в деле: написал с помощью AI-ассистента рабочее приложение на Python, который я почти не знаю. Точнее так: я понимаю суть того, что происходит, могу понять, как и что работает, но не знаю языковых конструкций, не знаю подводных камней языка, но точно знаю, что и как я хочу получить. Купил подписку на Cursor, поставил себе цель-вызов разобраться с вайб-кодингом.
Вернемся к проекту. Итак, есть цель: написать приложение на Python в Cursor API для извлечения текста из документов самых различных форматов. На вход в API передаем файл, на выходе получаем текст. Мы хотим с коллегами подготовить RAG для нашей базы знаний, чтобы можно было искать информацию с использованием AI и обучать по нашим данным. Тут, конечно, нужна целая инфраструктура, но начинаем мы с малого. Один из кирпичиков — это извлечение текста из всего, что можно.

▶️ Читать мою статью на Хабре: https://habr.com/ru/companies/softonit/articles/925716/
▶️ Скачать инструмент на GitHub: https://github.com/Diversus23/extract-text

Все абсолютно бесплатно.

Выводы: что точно могу сказать? AI — может. И да, это только начало. Но главная проблема в том, что ей надо четко ставить цели, писать ТЗ и корректировать ее работу, постоянно возвращая в рабочее русло. Я как-то объяснял не ИТ-шнику, что такое ИИ и как он работает, и нашел, как мне кажется, отличную аналогию.

Представьте, что ИИ — это бригада очень качественных строителей, при этом они не боятся работы, но не всегда тебя слушают, и если им покажется, что сделать по-другому будет лучше, или в твоих словах найдут несостыковки, то они сделают все по-своему. Говоришь: «Постройте мне стену», и они ее сделают. Но не из того материала, не там, где ты хотел, и не той толщины, но сделают на их взгляд отлично! ))) Улавливаете суть? Нужно точно говорить, где ставить стену, как ее строить, что в какой последовательности делать и из какого материала, тогда результат будет именно тот, который вы ожидаете. Ну и да. Нужен контроль. Все сделано? Надо проверить, нет ли в новой стене дырок, точно ли раствор тот и т. п.
Понятно, что это только начало, но даже так это отличный помощник, который может на себя забрать часть рутины (и не только).

Про людей, которые не умеют делегировать работу

Есть у меня одна знакомая главный бухгалтер, мы с ней в достаточно хороших отношениях, где-то даже немного доверительных. Мне всегда не нравилось, как она делает рабочие дела, которые ей нужно выполнить. Не в том смысле, что она ленится или непрофессионально относится к своей работе. Нет. Она слишком много тащит на себе.

В результате какие-то вещи она забывает (невозможно всё помнить), ее потом начинает есть совесть, это еще больше усугубляет ситуацию. Какие-то дела вынуждено игнорирует, т. к. сейчас «не до этого». Причем фирма не маленькая, дел много, а административной работой занимается явно меньше человек, чем это нужно.
Мои советы, мол, найди себе человека, который будет секретарем, чтобы снять с себя груз тех дел, которые легко можно переложить на другого. Или помощника главного бухгалтера, чтобы закрыл какие-то дыры. Идет молчаливое согласие и… Ничего не происходит.

Человек прекрасный. Отзывчивая, очень умная, технически подкованная, но неумение делегировать работу очень сильно ей мешает. Это прям видно. А отсюда:
* Переработки;
* Нервное напряжение;
* Работа мешает личной жизни;
* Аааа, караул! Я не успеваю сдать отчетность!
* Сегодня я легла спать в 4…

Ее отговорки в стиле «я сделаю работу лучше», «а кого?», «ну а кто сможет сделать это?» и т. п. я не понимаю и не принимаю.
Я это всё к чему. Умение делегировать — один из ключевых навыков любого руководителя. И да, его не преподают в вузе. Его не формирует опыт специалиста. Синдром отличника в полной красе: «если хочешь сделать хорошо — сделай сам».

Делегирование — это не отказ от ответственности. Это её грамотное распределение.

А вы умеете делегировать? Или тоже иногда не можете отпустить контроль?

Зачем вообще мне нужен блог по ИТ-тематике?

Сразу скажу, чего здесь не будет. Я не собираюсь становиться «лидером мнений», продавать курсы по «успешному успеху» или учить вас жизни. У меня нет цели понравиться всем или собрать армию подписчиков любой ценой.
Тогда зачем? У меня на это три честных и прагматичных причины.

Причина 1: Структурировать хаос. Мысли о проектах, управлении командой, коде, финансах и провалах постоянно роятся в голове. Блог — это способ разложить это все по полочкам. Превратить смутное ощущение или идею в четкий текст с аргументами и выводами. Это мой личный способ борьбы с профессиональным хаосом.

Причина 2: Проверить идеи на прочность. Я давно заметил: лучший способ понять что-то до конца — это попытаться объяснить это другому. Письменный текст беспощаден: он сразу вскрывает слабые места, нестыковки и откровенную чушь в твоей же аргументации. Для меня этот блог — публичный code review собственных мыслей. Если идея выдерживает попытку ее описать, значит, в ней что-то есть.

Причина 3: Зафиксировать опыт, в том числе негативный. Память — ненадежная штука, она любит сглаживать острые углы и приукрашивать победы. Блог — это мой личный «коммит» в репозиторий опыта. Чтобы через год можно было оглянуться и честно сказать: вот здесь я был прав, а тут — ошибался как первокурсник. Без этого нет роста.

Что здесь найдете вы?
Не теорию из книжек, а выводы из реальной практики управления IT-компанией. Разбор кейсов, провалов и инструментов, которые сэкономили мне время и деньги. Честный и прагматичный взгляд на IT-бизнес, без прикрас.

Если такой подход вам близок — подписывайтесь, где удобно. Будем на связи.

Telegram
VK
Dzen
Instagram
Facebook
Threads

Почему IT-одиночке почти невозможно запустить бизнес (и как всё-таки это сделать, если сильно хочется)

Вроде бы всё просто, но поди ж ты: спроектируй, напиши, сделай сайт, продай, занимайся маркетингом, SEO и прочее, прочее… В любом случае нужна команда. Многое из того, что нужно будет сделать, вообще не относится к создаваемому приложению, как это ни странно.

Сейчас сложное время. Это не начало 2000-х, когда ничего не было и был голубой океан. Сделав простую игру на мобилку, ты столкнешься со сверхплотным рынком издателей, которые выкупают ВЕСЬ трафик, и ты никак не пробьешься. Исключения есть, но они лишь исключения.

Путь соло-разработчика к бизнесу лежит не через создание прорывного продукта для масс, а через решение узкой, скучной, но болезненной проблемы для маленькой группы людей с помощью своей уникальной экспертизы.

Если бы я сейчас начинал, то сделал бы какой-нибудь пет-проект, который бы лечил чьи-то боли и как можно проще ниша.

- Плагин к Битрикс или WordPress
- Какие-нибудь парсеры сайтов
- Конвертации данных в 1С (когда нужно перейти с одной системы на другую)
- Простые обработки и отчеты для 1С, которых нет на рынке (но этого добра сейчас хватает)

А самое сложное — это даже не написать саму программу, а организовать всё, что связано с продажами и техподдержкой для клиентов (на мой взгляд).

Вы правда верите, что можете делать всё это хорошо в одиночку? Я — нет, хотя сам через это прошел. Сейчас бы мой подход и моя ниша точно бы не взлетели.
#Кейсы_КИД #Бизнес_КИД #Истории_КИД #РазборПродукта_КИД

История про Ларису и каблуки: как один паникер может развалить команду

У меня в отделе работала Лариса (имя изменено). Такой тип сотрудников, которых HR называет «высокоэмоциональными», а ты в голове называешь это иначе))

У этого человека была бесконечная потребность в диалоге. Она была профи в разработке, хорошо закрывала вопросы пользователей, да и вообще могла распутать любую проблему. Но есть один нюанс… Не заканчивающийся монолог и вовлечение других людей и бесконечный призыв к диалогу)))

Это ладно. Коллектив не должен быть однородным, мы все отличаемся друг от друга. Но, блин…

- У меня вот такие цветы…
- Мы с мужем жарили на выходных шашлыки…
- Мою дочь выгнали с общаги, она курила! Я ей устрою…

И так без конца и целый день. Были паузы и погружения в код, но потом поход к кулеру за водой и по новой. До сих пор не понимаю, как ей удавалось закрывать рабочие вопросы.

И как бы да, надоедает эта болтовня, но была еще одна и самая главная проблема — она была очень эмоциональной и, к сожалению, каким-то образом ее настроение передавалось коллективу. А это опасные игры для любого руководителя. На тот момент я был старшим разработчиком, и она была у меня в подчинении.

Было много разных вещей, которые переживали нерв рабочей атмосфере, но последней каплей стали каблуки… Мы работали на производстве, и кто-то где-то повредил ногу на лестнице из-за каблуков, каким-то образом родились сплетни, что в скором времени обязуют всех девушек/женщин ходить в туфлях без каблуков. Этот слух был активно подхвачен Ларисой, и понеслась…

- Я уволюсь. Это ненормально…
- Виталик, ты как считаешь, это правильно?
- Это дискриминация…

Я пытался успокоить, все же это слухи. Но какой там)) Забегая вперед скажу, что никто, конечно же, никаких запретов не вводил, и это были обычные сплетни/слухи. Но глядя на остальных коллег, я прям отчетливо понял, что если ничего не делать, то завтра я останусь один. Было неприятное напряжение в коллективе, которое отчетливо ощущалось. Задавались вопросы мне, но что я могу сделать со слухами? Революционер в коллективе, такое…

Пару раз говорил с ней и просил не делать из мухи слона, все слова были проигнорированы. В какой-то момент не выдержал и пригласил к себе. Поговорили, попросил ее не делать так и дождаться официального комментария руководства и не сеять панику на ровном месте, но нет. Человек не захотел и написал заявление на увольнение.

До сих пор не могу понять, что это было? Зачем каждого в коллективе привлекать к этим не подтвержденным слухам?

Что касается болтливости, то мне кажется, что человек пытался через болтливость заглушить свои страхи. В её случае это способ справляться с тревогой и выплеснуть лишние эмоции. А когда появлялся вот такой повод «с каблуками», то эта защита давала сбой, и тревога пробивалась через нее и выплескивалась на коллектив, мешая всем. Ни разу не психолог, но мне кажется, в этом что-то есть.

Можно ли с этим что-то делать? Если речь о самом человеке, то, думаю, да. Ему нужно к психологу. Лариса была умной, я думаю, психолог ей бы помог и подсветил все проблемы.

Может ли с этим что-то сделать руководитель? Вряд ли. Наверное, какой-нибудь ушлый руководитель мог бы как-то эту тревожность использовать и замыкать на проекте: «Слушай, у нас будут проблемы, и случится вот это, надо бы тебе взяться за этот проект» и дальше подпитывать эти страхи. Но это, на мой взгляд, неэтично по отношению к сотруднику. Потому что после таких переключений человек может загнать себя в еще большие переживания, и будет только хуже. Лучшим вариантом, на мой взгляд, к сожалению, будет расставание с таким сотрудником.

Моя ошибка в этом тоже есть, хотя ее и не видно с первого взгляда. Возможно, я долго игнорировал ее особенности и дождался «каблуков». Сотрудник, который дестабилизирует коллектив слухами и паникой, обходится компании дороже своей зарплаты. Мы платим за это падением производительности всей команды, вовлечением руководителя в тушение пожаров и риском потерять других, более стабильных людей.

Грустно, ну а куда деваться?
#Кейсы_КИД #Истории_КИД

Google выпустил шрифт для кодеров. Меняем JetBrains Mono на Google Sans Code?

Казалось бы, чем еще можно удивить в 2025 году разработчика? Новым JavaScript-фреймворком? Очередной революционной IDE? Нет. Google решил зайти с основ и выпустил новый моноширинный шрифт, созданный специально для кода — Google Sans Code.

Обещают все, что мы любим: идеальную читаемость даже на крошечных размерах, четкие геометрические формы и «каллиграфический шарм». Заявляют, что он спроектирован так, чтобы снижать нагрузку на глаза и помогать быстрее разбираться в коде.
Конечно, это все звучит прекрасно. Но мы-то с вами знаем, что выбор шрифта для редактора кода — это почти религиозный вопрос. Я сам уже несколько лет сижу на JetBrains Mono, считаю его практически эталоном прагматичности и читаемости, и полностью им доволен. Мы привыкаем к нашему инструменту, и эта мышечная память — часть рабочего процесса.
Так стоит ли переходить?

Скептик во мне говорит, что реальный прирост продуктивности от смены одного хорошего шрифта на другой — величина, стремящаяся к нулю. Главный вопрос не в том, «хорош ли новый шрифт от Google?», а в том, «настолько ли он лучше моего любимого JetBrains Mono, чтобы я потратил время и усилия на то, чтобы к нему привыкнуть?»

Но мне новый шрифт нравится. Что сами юзаете?
#РазборПродукта_КИД https://vk.cc/cOid5Q

Пока 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 молодцы, но это не конец. Думаю ситуация не статична и время от времени лидеры будут меняться. Тем лучше для обычных пользователей.

Тут OpenAI презентовала вчера новую модель GPT-5. Обещают светлое будущее и что все будет лучше чем вчера. Но меня больше интересуют графики, которые они предоставили.

С каких пор 52.8% больше 69.1, а 69.1 равно 30.8 😁

Кейс: Как сократить время замены картриджа с 2 дней до 10 минут без дополнительных затрат

На одной из конференции Infostart Event услышал управленческий кейс от коллеги, ИТ-директора Сергея Горшенина, который идеально иллюстрирует принцип «гениальное — просто».

🔥 Проблема: два дня на замену картриджа

Представьте крупное предприятие с территорией, по которой сотрудники передвигаются на автобусах. IT-отдел небольшой. Когда у кого-то заканчивается тонер, особенно в отчетный период, появляется проблема. Специалист тратит время на дорогу, чтобы просто поменять картридж. В итоге рабочее место простаивает день, а то и два.

IT-отдел превращается в курьерскую службу, а бизнес теряет время.

Прежде чем читать дальше, поставьте себя на место руководителя. Какое нетехническое, управленческое решение вы бы приняли, не имея бюджета на расширение штата?

<...пауза на подумать...>

💡 Решение: изменить парадигму

Ключевая мысль, к которой пришел Сергей, была простой: кто быстрее всех узнает, что картридж закончился? Сам пользователь. А что, если он сам его и принесет?

Схема была реализована в три шага:

1. Создание ценности. Пользователям, которые жаловались на простой, задавали вопрос: «Хотите, чтобы замена картриджа занимала 10 минут вместо двух дней?». Ответ был очевиден.
2. Разовое обучение. В обмен на скорость специалист IT один раз приезжал к пользователю и обучал его простому действию: как вынуть картридж из МФУ и вставить новый.
3. Организация «обменного пункта». На складе IT-отдела был создан резерв картриджей. Теперь пользователь сам приносил пустой картридж и мгновенно получал заправленный. Никаких поездок со стороны IT, никаких простоев.

🤔 Вывод

На мой взгляд, гениальность этого решения — в смене парадигмы. Вместо того чтобы оптимизировать неэффективный процесс (как специалисту быстрее ездить?), его полностью перестроили, задав правильные вопросы:

- Кто владелец проблемы? Пользователь.
- Какую ценность мы можем ему предложить? Скорость.
- Что мы просим взамен? Простое действие, которое экономит всем кучу времени.

Как говорил Сергей Королев: «Каждый может сделать сложно, а ты попробуй сделать просто». Этот кейс — прямое тому доказательство.

Интересное решение.
#Бизнес_КИД #Кейсы_КИД

Эффект «стены Дурова», который я открыл за 10 лет до самого Дурова

По студенчеству я, как и любой джун, совершал ошибки. Одна из них — классический пример истины «работает — не трожь».

2004 год. Я на 3-м курсе факультета прикладной математики и информатики АГУ (г. Майкоп), параллельно работаю программистом в математической школе при университете. Моя вотчина — программа для подсчёта рейтингов учеников, набор текстов для методичек и небольшой сайт с гостевой книгой.

Кто не застал — гостевая книга тогда была чем-то вроде бесконечного чата без регистрации. У детей мат. школы в ней кипела жизнь: по 100–200 сообщений в день (иногда даже больше), свои шутки, обсуждения задачек, разговоры «за жизнь». Формат был простой и лёгкий — написал ник, сообщение, и готово.

А я молодой, амбициозный и несу людям счастье)))

Я тогда подумал. Почему они мучаются с этим бесконечным тредом сообщений? Это же жутко неудобно! А что если я уберу эту гостевую книгу и заменю ее на удобный форум для своих? Хорошая же идея? Ну, если судить логически, то да. Свой форум, регистрация, понятно, кто пишет, можно делать свои темы и не тонуть в бесконечной беседе. На тот момент мне казалось, что это отличная идея сделать жизнь определенного круга людей лучше.

Нашел хороший движок форума и в один прекрасный день заменил гостевую книгу на этот форум. Создал темы и стал ждать, как мне люди скажут спасибо.

Догадываетесь, что было дальше? )))

Правильно. Провал… Ученики не стали использовать новый форум!

Была попытка одного человека что-то написать, но когда никто не ответил, то и он перестал что-то писать + пара регистраций пользователей. Моя попытка это исправить ни к чему не привела. Я даже старые сообщения пользователей из гостевой книги загрузил в новый форум. Все бестолку. Сайт, у которого был отличный трафик, буквально за неделю перестали посещать.

Для меня это было потрясение. Как так вообще? Я же хотел сделать как лучше для пользователей! Почему они не стали использовать новый форум?

Как всегда, рефлексия и мои мысли на эту тему прилагаются:

- Новый форум не взлетел, т. к. старый был ламповый, легкий. Можно добавить одну запись под ником «Препод такой-то», а следующую «Иванов Иван». Было интересно переписываться в таком легком формате. Был вайб от использования такого формата. Может, помните в VK знаменитое: «Дуров, верни стену!»? Этот косяк Павла из той же оперы.
- Если какой-то сервис работает хорошо, но, на твой взгляд, там все организовано очень нелогично, не надо это исправлять сию минуту! Надо сделать опрос, проверить гипотезы, попробовать узнать мнение пользователей. Бывает, конечно, и такое, что пользователи не могут тебе сказать, что нужно добавить, и при добавлении этого «чего-то» оно действительно взлетает, но делать это нужно аккуратно, просчитывая варианты.
- Этот студенческий урок 20-летней давности я вспоминаю до сих пор каждый раз, когда моя команда в Софтонит предлагает «быстро улучшить» какой-нибудь работающий модуль. Часто при взгляде на проблему задаю себе вопрос: «Какую настоящую работу выполняет для пользователя этот старый, неудобный, но привычный функционал? И не убьем ли мы ту самую «ламповость», просто заменив ее на «правильное» решение?»

Вот такая история.

P. S. Если кто-то читает мой пост из тех, кто тогда сидел в этой гостевой книге, прошу у вас прощения. Я не хотел, чтобы так все вышло.
#Истории_КИД #РазборПродукта_КИД

30 лет без дизайна и миллиард в кассе

На днях я рассказывал историю о том, как в 2004-м «улучшил» простую гостевую книгу, заменив ее на «правильный» форум и этим убил живое сообщество. Главный вывод был в том, что нельзя ломать работающую систему, не поняв, какую настоящую задачу она решает для пользователей.

А сегодня я наткнулся на статью на VC.ru, которая служит идеальной иллюстрацией этого принципа в промышленных масштабах. Речь о Craigslist.

Ссылка на статью: Craigslist — древнейший стартап с миллиардной выручкой

Для тех, кто не в курсе: Craigslist — это что-то типа Авито, но в США, т.е. такая гигантская доска объявлений. Ее дизайн застрял где-то в 1998 году: синие ссылки, простейшая верстка, ноль графики. По любым современным меркам UI/UX — это катастрофа. При этом компания с крошечной командой зарабатывает сотни миллионов (а по некоторым оценкам — более миллиарда) долларов в год. Работает там от силы 50 человек (!) Если пересчитаем выручку, то окажется, что на каждого сотрудника приходится 4 млн. долларов в год (!) 🤯 Очень круто!

И тут я смотрю на Craigslist и понимаю: их «ужасный» сайт — это моя «неудобная» гостевая книга, только в масштабе всей Америки. Они поняли то, чего не понял я в 20 лет, и не стали «чинить» то, что не сломано.

Почему этот «примитивный» дизайн работает и приносит миллиарды?

- Скорость. Сайт загружается мгновенно. Нет тяжелых фреймворков, мегабайтов JavaScript и аналитических скриптов. Чистая функция.
- Плотность информации. Никаких баннеров, всплывающих окон и модных карточек. Только текст и ссылки. Вы видите максимум полезной информации на одном экране.
- Отсутствие трения. Хочешь разместить объявление? Нажимай и размещай. Не нужна регистрация (как я понял), подтверждение почты и двухфакторная аутентификация, чтобы продать старый стул. Сервис не мешает тебе делать то, зачем ты пришел.
- Привычка. Миллионы людей пользуются им десятилетиями. Они знают каждую ссылку наизусть. Любой редизайн вызовет у этой аудитории не восторг, а гнев. Они потеряют свой привычный и предсказуемый инструмент.

Мой «улучшенный» форум вводил трение: регистрация, создание тем, сложная структура. Я убил легкость и анонимность. Точно так же любой «современный» редизайн Craigslist с React, модными анимациями и персонализацией убьет его главное преимущество — скорость и простоту.

Вывод для любого IT-руководителя:

Это вечный соблазн для любого технаря — переписать старое, «кривое», но работающее легаси на новый, блестящий стек. Нам кажется, что мы сделаем «лучше». Но главный вопрос: «лучше» для кого? Для вас или для пользователя, который просто хочет за 3 секунды решить свою задачу?

Craigslist — это гениальный пример бизнес-прагматизма. Он доказывает, что иногда лучшая фича — это ее отсутствие. А самый ценный актив компании — это привычка пользователя, которую нельзя ломать без крайней необходимости.

А в вашей практике есть свой внутренний «Craigslist»? Старый, неудобный, но незаменимый сервис, который все мечтают переписать, но боятся трогать?
#Истории_КИД #Бизнес_КИД

Качество техподдержки падает из-за нейросетей

Помните, был такой лайфхак, когда для связи с оператором Сбера просили бота ответить на вопрос «период полураспада радия/плутония» и бот в панике сразу переводил на оператора? Потом это пофиксили, но я этот случай запомнил.

На днях увидел, что ребята на 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
#Истории_КИД

Переход 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С и цвет. Как из одной строчки HEX-кода выросла целая библиотека

Все началось с банальной задачи. Я хотел нормально сохранять настройки цветов в конфигурации «Управление 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_КИД #Инструменты_КИД