Нейронки конечно могут… Взял ради прикола текст предыдущего поста и добавил в промпт:

Преобразуй этот документ в красивую HTML-страницу с современным дизайном:

[ВСТАВЬ СВОЙ ТЕКСТ/ДОКУМЕНТ]

Требования к дизайну:
- Современный стиль с градиентами и тенями
- Плавные анимации при скролле
- Адаптивный дизайн для мобильных
- Красивая типографика с контрастом
- Интерактивные элементы (hover-эффекты)
- Используй карточки для блоков информации
- Добавь цветовые акценты и иконки

Создай полный HTML файл с встроенным CSS и JavaScript.

Вставил это сначала в бесплатный Qwen, а потом в ChatGPT 5

Получились прям продающие страницы 🙂

Взгляните-ка на скриншот. Вот так выглядит оформление от ChatGPT. Qwen тоже получилось не плохо, ниже скину ссылка для того, чтобы поглядеть.

Что это дает обычному пользователю?

Мы можем красиво и абсолютно бесплатно преобразовать любой скучный текст в красивый HTML-документ, сохранить его потом в PDF и отправлять клиентам. Или прям так отправлять. Таким же образом можно делать:

- Коммерческие предложения
- Презентации
- Портфолио
- Гайды, уроки, инструкции

И все это можно сделать бесплатно в Qwen. В ChatGPT у меня подписка, но думаю и там можно на бесплатном тарифе что-то подобное сделать.

На всякий случай прилагаю оформление в виде архивов с HTML, которые можно скачать и посмотреть:

ChatGPT
Qwen

Я решил убить старую базу знаний на Битрикс с документацией по нашим продуктам. Часть 1

Меня беспокоит наша база знаний с документацией по нашему ПО на сайте. Она выглядит не особо и содержит ряд фундаментальных проблем, которые портят жизнь как разработчикам, так и пользователям.
Сайт Софтонит сделан на Битрикс, и изначально мы выбрали встроенный в эту платформу механизм для создания базы знаний. Это было в 2016 году, и на тот момент казалось, что всё выглядит хорошо и в целом всё удобно и классно.

Надо зайти и изменить статью? Открываешь админку сайта, заливаешь картинки, добавляешь текст статьи на сайте, и она сразу же отображается для клиентов. Удобненько (как тогда казалось).

Время идет, всё меняется, и вот уже ты видишь проблемы со старым подходом:

- В Битрикс оказывается неудобный встроенный редактор статей. Редактируешь статью, сохраняешь, в админке она выглядит так, а для пользователей верстка едет. Переключаешь в режим HTML, а там левые теги. Приходится их вычищать.
- Понимаешь, что есть проблемы с добавлением и изменением изображений. Нельзя вставлять изображения в статью из буфера обмена. Также изображение добавляется в медиабиблиотеку, а стандартный редактор использует уже изображение оттуда. В целом это работает не очень быстро. Процесс обновления одного скриншота превращается в квест из девяти кругов ада: сделай скриншот, сохрани файл, зайди в админку, открой медиабиблиотеку, загрузи файл, скопируй ссылку, вернись в статью, вставь ссылку… Хочется просто перетащить картинку в редактор, а вместо этого ты тратишь 10 минут на рутину. А если нужно поменять 20 картинок? Это просто воровство времени у команды разработки. Жесть.
- Плохой поиск. Прям очень. Было пару раз, что поиск отваливался в базе знаний после обновления Битрикс, и за мной ходила менеджер по продажам и говорила, как ей показывать какие-то фичи клиентам и отвечать на их вопросы, если она не может ничего найти в базе знаний. А изменить ты особенно ничего не можешь. Не будешь же править Битрикс и искать, в чём косяк. Потом это, конечно, всё восстанавливалось со следующими обновлениями, но осадочек от этого остался.
- Но всё это мелочи по сравнению с главной проблемой, которая меня бесит: документация живёт своей жизнью, отдельно от кода. Разработчик выкатил фикс, а документация осталась старой. В итоге клиент читает одно, а в программе видит другое. Это прямой путь к потере доверия. И именно этот разрыв стал для меня последней каплей.
Я задумал на сайте Софтонит заменить старую документацию и использовать концепцию Docs-as-Code. Что это вообще за концепция?

Всё просто — работаем с документацией так же, как и с исходным кодом программы. Заводим папочку «docs», и все скриншоты и файлы в текстовом формате (обычно это markdown) пишем и изменяем тут же, а потом пушим всё в Git. При пушах срабатывает линия сборки, которая автоматически разместит документацию на нашем сайте. При таком подходе мы получим:

- Версионирование документации. Удобно видеть версии документации.
- Документация соответствует коду, который изменяется, и она обновится тогда, когда мы выпустим релиз. Т.е. документация следует за кодом (но тут всё зависит от того, как вы настроите линию сборки).
- Можно использовать любимые markdown-редакторы. Лично мне нравится редактор Visual Studio Code и плагин для Markdown. Оно умеет и из буфера файлы вставлять в текст, и даже есть свой линтер для формата Markdown (подчеркивает желтым, если ты что-то не так делаешь в оформлении текста).
- Мы отделяем текст документации от оформления этого текста на сайте. Есть куча генераторов статических сайтов, которые потом используют нашу доку, это всё сопрягается вместе, и мы получаем красивые мини-сайты с нашими markdown-файлами. Всё это работает очень быстро и выглядит очень круто. Там и встроенный поиск, и красивые стили, и адаптивность и т.п.
Но это всё теория! 🙂 Легко всё на бумаге, но вот внедрить всё это будет непросто. У меня пока нет готового решения.

Я пока не определился, что использовать в качестве генератора статических сайтов и как организовать сборку для всего нашего ПО. Есть такие инструменты, как Diplodoc, Docusaurus, Hugo, MkDocs или Gatsby, и они часто применяются для таких целей. Но на каком остановиться, пока не ясно.

В общем, начинается эпопея под названием «Убираем старое и ставим новое» 🙂

Это первая часть серии статей по разворачиванию новой базы знаний и изменению старых механизмов. Буду держать в курсе, что выберу и как это потом настрою.

А на чём живёт ваша документация? Тоже страдаете, как мы сейчас, или уже нашли самый лучший инструмент для документации?

PS: Продолжение следует…
PPS: Скриншоты можно посмотреть в оригинале статьи

От Битрикс к Git. Муки выбора и почему победил Docusaurus. Часть 2

В прошлом посте я написал почему наша старая база знаний на Битриксе — это боль. Редактор кривой, поиск отваливается, а документация живет отдельно от кода. Надоело.

Решил перевезти всю документацию на новый генератор статических сайтов по принципу Docs-as-Code. Но какой выбрать? Hugo, MkDocs, Diplodoc от Яндекса?..

Подсказка пришла, откуда не ждал — посмотрел, на чем сделаны базы знаний Сбера и Т-Банка 😉. Оказалось, гиганты используют один и тот же инструмент.

Мой шорт-лист и финальный выбор:

❗ Задача: Найти быстрый движок с крутым поиском, чтобы не страдали ни клиенты, ни сотрудники.
🔥 Ключевые критерии: Скорость сборки, поиск Algolia, плагины и живое комьюнити.
💡 Победитель: Docusaurus.

Рассказал в новой статье, почему именно он, как сэкономил кучу времени на анализе и интересные выводы со скриншотами по другим движкам.

➡️ Читать полную статью: https://codeitdir.ru/products/kb-2/?utm_source=Telegram&utm_medium=social&utm_campaign=26292908

Ваш главный проект — это вы. Как управлять своей жизнью

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

Я внедрил проектный подход к своей жизни, превратив её в систему: с целями-«эпиками», месячными «спринтами» и обязательными «ретроспективами» каждую неделю. Мой опыт показал, что это работает.

В статье подробно рассказываю:

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

Какие IT-аналогии помогают мне структурировать личные задачи (от Kanban до Git).

Когда проектный подход к жизни может превратиться в паранойю и как этого избежать.

Мой личный опыт и примеры.

Хватит плыть по течению, пора взять управление в свои руки! 👇

Читать подробнее

1С и искусственный интеллект. Почему «1C:Напарник» — это только начало большого отставания?

Недавно поймал себя на мысли, что AI-ассистент в 1C:EDT, 1C:Напарник, заметно уступает тому же Cursor. Да, он помогает и автодополнение кода — это лучше, чем ничего. Но разница в качестве подсказок колоссальная.

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

Возможно я не прав и работа ведется давно, но 1С в этом плане не публичная компания. Что она развивает мы узнаем только по факту, когда выйдет первый релиз того, над чем работают.

Я вижу три фундаментальные проблемы, которые мешают 1С быстро сократить разрыв в ИИ:

Проблема №1: Архитектура и контекстное окно. Любая серьёзная конфигурация 1С — это гигантский объём метаданных и тысячи модулей. Даже топовые нейросети сегодня упираются в лимит контекстного окна. Как «объяснить» модели всю логику огромной ERP-системы, чтобы она писала качественный код, а не галлюцинировала? Архитектурно это очень сложная задача.

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

Проблема №3: Локальный язык. Модели вроде GPT обучаются на триллионах токенов кода с GitHub и всего интернета. А сколько в открытом доступе качественного кода на 1С? Язык — локальный, для рынка СНГ. Этого объёма данных катастрофически мало для обучения действительно мощной модели, которая будет понимать всю специфику платформы.

Что у 1С есть сейчас в арсенале ИИ? Если честно, немного:

- 1С:Напарник: Помощник с автодополнением кода.
- Распознавание документов: Полезно, но это уже стандарт индустрии, а не прорыв.
- Таймлист 1С: Расшифровка встреч. Тоже полезная утилита.

И, кажется, всё.

Я очень люблю платформу 1С и хочу видеть её на острие технологий. Но пока картина выглядит тревожно. Время покажет, сможет ли компания совершить технологический рывок.

Коллеги, а что вы думаете? Есть у 1С шансы догнать тренды? Или её нишевость в итоге станет её же ловушкой в мире повсеместного AI? Делитесь мыслями в комментариях.

Как мой начальник «победил» юристов без единого скандала. Урок корпоративного Win-Win

Мне повезло. В самом начале своей карьеры я был под руководством толкового руководителя. Он был на несколько лет старше, но гораздо более опытнее в плане руководства в ИТ. Много фишек по управлению я подсмотрел именно у него.

Особенно в память врезалась одна история.

Ситуация: Пат

Представьте крупную компанию. IT-отдел постоянно что-то закупает. Юридический отдел — «любимчики» руководства, чувствуют свою власть и могут завернуть любой договор, прикрываясь «интересами компании». Даже там, где можно было легко договориться.

Нам срочно нужно оборудование. Оно есть только у одного поставщика в РФ. Поставщик дает свой типовой договор. Наши юристы — свое решительное «нет», требуют переделать всё под наш шаблон. Поставщик, устав от правок, вежливо посылает нас.

Тупик. Оборудование нужно как воздух. Юристы договор не пропускают. Без их визы никто ничего не оплатит.

Развязка: Картридж как рычаг давления

Иван не стал ругаться и писать докладные. Он взял паузу на пару дней.

Через некоторое время в наш кабинет заходит та самая сотрудница юротдела, которая курировала наш договор, и просит: «Вань, у нас картридж в МФУ закончился, а мне нужно срочно печатать кучу документов для суда. Заправьте, пожалуйста».

И тут Иван спокойно, без наезда, раскладывает пасьянс: «У меня тут ваш договор от единственного поставщика лежит. Оборудование купить не можем, всё стоит. Поставщик нашу редакцию не принимает».

Юрист всё поняла и улыбнулась.

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

Они помолчали, глядя друг на друга. Затем она встала, дошла до двери, обернулась и сказала: «Приносите ваш договор…»

Когда она ушла, Ваня рассмеялся. Ни грамма грубости, никакого хамства. Просто два человека поняли интересы друг друга и договорились. Классический Win-Win.

Уроки, которые я извлек тогда и использую до сих пор

1. Ищите неформальные рычаги. Когда формальные процедуры заходят в тупик, ищите точки пересечения интересов в операционной плоскости. IT-отдел, как сервисная служба, имеет массу таких рычагов: от скорости реакции на заявку до приоритета в закупках.
2. Пауза — это стратегический ресурс. Мгновенная эскалация конфликта — признак слабости. Иногда нужно просто подождать, пока у оппонента не появится проблема, которую вы можете решить.
3. Авторитет зарабатывается решением проблем, а не криком. Иван не просто «прогнул» юристов. Он показал, что с ним можно и нужно договариваться. В следующий раз они дважды подумают, прежде чем бездумно блокировать его инициативу.

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

Вспоминаю Ивана с огромной благодарностью. Он многому меня научил.

А как у вас выстроены отношения с юристами и бухгалтерией? Часто приходится «воевать» или находить нестандартные решения? Делитесь в комментариях!

Политика нулевой терпимости к багам в разработке ПО. Ловушка для перфекциониста или отличная штука?

Столкнулся недавно с идеей «Zero Bug Policy» (ZBP). Речь про политику нулевой терпимости к багам. Концепция простая: увидел баг — бросай всё и чини. Звучит как мечта: ошибки все исправлены, клиенты счастливы, а техподдержка пьет смузи.
Но мой опыт показывает, что такие лозунги часто ведут в ад переработок и демотивации. Давайте разберемся, почему ZBP — это чаще всего утопия, которая может навредить бизнесу больше, чем помочь.
На бумаге все выглядит классно:
- Нашли баг? Все бросаем и чиним. Никаких новых фич, пока в бэклоге есть хоть одна ошибка.
- Результат? Код всегда в идеальном состоянии. Качество продукта стремится к 100%.
Звучит как мечта любого IT-директора. Но дьявол, как всегда, в деталях.

Почему это почти никогда не работает

1. Экономика против. Представьте, что вы делаете уборку в квартире. Убрать 95% грязи можно быстро и легко. А вот вычистить оставшиеся 5% проблемно. Пыль за шкафом, налет на кране займет столько же времени, сколько вся предыдущая уборка. В разработке тот же принцип Парето, только в кубе. Исправление 80% багов занимает 20% времени. А вот охота за последними, редкими и трудновоспроизводимыми ошибками — это колоссальные затраты. Стоит ли неделя работы разработчика исправления бага, который возникает у одного пользователя из тысячи при специфическом стечении обстоятельств? С точки зрения бизнеса, думаю почти никогда.
2. Что вообще считать «багом»? Вот тут и начинается самое интересное.
- Опечатка на кнопке это баг?
- Неидеальное выравнивание элемента на странице при разрешении экрана 1366×768 тоже баг?
- Отсутствие валидации на редко используемом поле точно баг?
Если команда обязана исправлять всё, она утонет в мелочах. Разработчики будут тратить время на косметику, вместо того чтобы пилить фичи, которые приносят деньги. Бизнес за это спасибо точно не скажет.
3. Цена промедления. Пока ваша команда гоняется за съехавшей кнопкой, конкуренты выкатывают новые функции и захватывают рынок. Бизнес теряет не только деньги на зарплатах разработчиков-перфекционистов, но и упущенную выгоду.

Здравый смысл вместо утопии. Сортируем баги

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

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

Когда ZBP имеет смысл?
Но не все так однозначно. Есть области, где цена ошибки — это человеческая жизнь или миллионные финансовые потери. Софт для больниц, автопилоты, системы управления АЭС и т.п. Там ZBP жизненная необходимость, подкрепленная бюджетами и сроками (например, многоуровневым тестированием).
Но давайте будем честны, большинство из нас не пишет софт для NASA. Наша задача создавать ценность для бизнеса, а не стремиться к недостижимому идеалу.

Вывод: Zero Bug Policy красивая, но опасная идея для большинства компаний. Она подменяет цель (создание работающего и прибыльного продукта) средством (достижение стерильного кода). Гораздо эффективнее внедрить четкую систему классификации багов и принимать решения, основанные на здравом смысле и экономике.

А как у вас в компаниях работают с багами? Делитесь опытом в комментариях.

Неожиданная встреча с клиентом и мой фейл

В пятницу на прошлой неделе к нам в гости заехал Сергей Владимирович, представитель нашего клиента, они в своей работе используют Управление IT-отделом 8. Для меня это необычный кейс. Наш офис находится в маленьком городе в Краснодарском крае, и сюда ехать не ближний свет. Основные клиенты — это крупные компании, которые находятся совсем не близко. Клиент хотел поближе познакомиться, так как был проездом рядом и у него недалеко живут родственники.

После новости, что к нам едет клиент, сразу подумал: «Что? Зачем? Почему?» 😁
А потом понял. Это уникальный шанс «помучать клиента» и задать острые вопросы, узнать кейс нестандартного использования и т. д. Но и клиент может сделать ровно то же самое по нашему ПО: задать неудобные вопросы и узнать планы на будущее.

На мой взгляд, я плохо подготовился. Самый главный фейл — это то, что оказалось у нас два клиента с одинаковой фамилией, и когда я готовился к встрече, я посмотрел на данные другого клиента, на имя и отчество не обратил внимание. 🤦 Из-за этого и вопросы подготовил чутка не те… В общем, вы поняли.

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

Чуть позже отдельно выложу, что из этого получилось в виде кейса клиента.

В связи с этим у меня к вам пара вопросов:
- Про фейлы: было такое, что при важной встрече всё шло, мягко говоря, не по плану?
- Про продукты: сталкивались с тем, что ваш или чужой софт использовали совсем не так, как задумывали разработчики? Расскажите в комментариях, это же самое интересное!

Налоги для IT с 2026 года: закручивают гайки?

Не дает мне покоя тема с налогами. Повышение ставки НДС с 20% до 22% — это ещё полбеды. Куда больше беспокоит снижение порога для УСН, после которого придётся платить НДС. Его хотят урезать с 60 млн до 10 млн рублей. Если это примут, а всё к тому идёт, то наша компания тоже попадёт на НДС.
Есть в экономике такая штука, кривая Лаффера. Она просто и наглядно показывает: если налоги 0%, то в бюджет ничего не поступает. А если 100%, то бизнесом заниматься нет смысла — весь доход уйдет на налоги. Где-то посередине есть точка, в которой государство собирает максимум. Если ставку задрать выше этой точки, сборы начнут падать, потому что предприниматели просто не вывозят нагрузку. Бизнес перестаёт развиваться, теряет позиции, а потом и вовсе работает в убыток. В итоге он либо закрывается, либо уходит в тень.

Мне всё это, мягко говоря, не нравится.

А с IT-компаниями вообще история весёлая.

Как менялись льготы для IT-компаний

Давайте посмотрим на динамику налоговых условий для аккредитованных IT-компаний, в том числе тех, кто на УСН. Собрал тут для себя и вас изменения (если что-то забыл, напишите поправлю):

- Налог на прибыль:
2022-2024: 0%
2025-2026: 5% (планируется до 2030 года)
- Страховые взносы:
2022-2024: 7,6%
2025: 7,6%
2026: 15% (на доходы до предельной базы) и 7,6% (сверх базы)
- НДС для разработчиков ПО:
2022-2026: 0% при продаже софта из реестра Минцифры. Но есть нюанс: условия для попадания в реестр могут ужесточить.
- Льготы на УСН:
2022-2025: Регионы сами устанавливали пониженные ставки (от 1% до 6%).
2026: Ставки сохраняются, но порог для освобождения от НДС падает с 60 до 10 млн рублей годового дохода.
- Проверки:
2022-2025: Действовал мораторий на большинство проверок.
2026: Условия, скорее всего, пересмотрят.

Что нас ждёт в 2026 году?

Прогнозы — дело неблагодарное, но вот основные изменения, которые маячат на горизонте.

1. Страховые взносы вырастут почти вдвое. Льготный тариф поднимут с 7,6% до 15%. Это, конечно, не стандартные 30%, но рост ощутимый.
2. Главный удар для малого бизнеса на УСН. Порог для освобождения от НДС рухнет с 60 до 10 млн рублей. Это значит, что даже небольшие IT-компании с оборотом чуть выше 10 млн в год заставят платить НДС, который тоже может вырасти до 22%.
3. Льгота по НДС на софт пока остаётся. Ставка 0% на продажу программ из реестра Минцифры сохранится. Правда, есть подозрение, что на фоне общего повышения налогов попасть в этот самый реестр станет намного сложнее.

Получается, что золотые времена для IT с почти нулевыми налогами заканчиваются. С 2025 года гайки начали закручивать, а в 2026, похоже, закрутят ещё сильнее. Льготы всё ещё есть, и они заметны по сравнению с другими отраслями, но уже не такие щедрые.

Интересно, что вы думаете об этом? Как готовитесь к изменениям? Делитесь мыслями в комментариях.

IT и бухгалтерия: как прекратить споры за каждую мышку. Пример из жизни.

Недавно я писал про встречу с клиентом и свою ошибку в подготовке. Эта встреча принесла пользу. Мы записали наш разговор и сделали из него подробный отчет. Сегодня я расскажу о самом важном из этого отчета — как IT-отдел и бухгалтерия могут прекратить споры.

Полный отчет вы можете найти на сайте SoftOnIT: ccылка на полный кейс

В чем проблема: два разных взгляда

Споры между IT и бухгалтерией почти всегда касаются учета оборудования.

Как видит бухгалтерия: Любая вещь, будь то ноутбук или мышь, — это актив компании. Его надо записать, дать ему номер и назначить ответственного. Обычно это тот, кто вещью пользуется. Каждое движение техники требует бумажного документа. Чтобы что-то выбросить, нужна своя процедура.

Как видит IT-отдел: Оборудование постоянно двигается. Сегодня ноутбук у одного человека, завтра — у другого. Мышь меняется за минуту. Диск в сервере сломался — его выкинули. Если для каждого такого шага готовить документы для бухгалтерии, IT-специалисты будут заниматься только бумагами.

Результат: все недовольны, а в учете беспорядок.

Как клиент решил задачу: разделить ответственность

Наш клиент — компания, у которой есть заводы и офисы в разных местах. Они придумали простой способ. Главная идея: ясно поделить, кто за что отвечает, и закрепить это официальным документом.

Как это у них устроено:

1. Вся ответственность на IT-отделе. По внутреннему приказу, вся компьютерная техника находится в ведении IT-отдела. Руководитель IT отвечает за все оборудование в компании.
2. Бухгалтерия общается только с IT. Когда поступает новая техника, бухгалтеры ставят ее на учет и сразу передают IT-отделу по акту. На этом их работа с конкретной вещью закончена до момента списания. Они работают с общими цифрами и документами от IT.
3. IT-отдел ведет свой учет. В нашей программе (Управление IT-отделом 8) специалисты следят, где находится каждая единица техники. Они отмечают, что ноутбук выдан такому-то человеку, но это их внутренняя запись. Для бухгалтерии этот ноутбук все еще числится за IT-отделом.
4. Ответственность сотрудника. Получая технику, работник подписывает документ о передаче с IT-отделом. Если он что-то потеряет, отвечать будет перед IT. Руководство компании знает и поддерживает этот порядок.
5. Простое списание. IT-отдел готовит документ о техническом состоянии и отправляет бухгалтерам записку: «Просим списать 5 единиц оргтехники на такую-то сумму». Этого бухгалтерии хватает, чтобы провести операцию.
6. Минусы тоже есть. Куда ж без них. За удобство приходится платить тем, что за все отвечает ИТ-подразделение. Но если контакт с бухгалтерией найден, то это, наверное, не такая уж и проблема.

Что это дает?

- Бухгалтеры довольны. Им больше не нужно отслеживать сотни мелких вещей. Они общаются с IT при помощи понятных им документов и цифр.
- IT-отдел получает больше времени на работу. Специалисты могут быстро управлять оборудованием и не тратят время на лишние бумаги.
- В учете все ясно. Деньги считает бухгалтерия. Фактическим наличием техники управляет IT. Путаницы нет.

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

А как у вас построена работа с бухгалтерией? Удалось договориться или вы спорите из-за каждого старого жесткого диска? Напишите в комментариях!

Perplexity AI: Заменит ли он Google? Мой опыт и опасность покупки за 500 рублей

В последние три недели я почти не использую обычный поиск Google или Яндекс. Всё из-за Perplexity AI. Это поисковик с нейросетью, который понимает смысл вопроса, а не ищет по словам. Он выдает не просто список сайтов, а готовый ответ по делу, со ссылками на источники.

Звучит хорошо, но официальная подписка стоит $20 в месяц. А в интернете её можно купить всего за 500 рублей на год (можно купить на Яндекс маркете, ggsel, plati и прочих площадках). В чём тут хитрость? Посмотрим, что это за программа, откуда такая низкая цена и есть ли смысл её покупать.

Что такое Perplexity и как он работает?

Проще говоря, Perplexity — это смесь поисковика и чат-бота типа ChatGPT. Работает он не так, как обычный поиск:

1. Вы пишете вопрос обычными словами. Программа понимает, что вы хотите узнать.
2. Perplexity быстро ищет в интернете, выбирая подходящие сайты.
3. Искусственный интеллект собирает найденные сведения и делает из них один ясный ответ.
4. Вы видите готовый текст со ссылками на сайты, откуда взята информация. Это главное удобство — можно легко всё проверить.
5. Можно спрашивать дальше, чтобы уточнить детали. Программа помнит ваш разговор и продолжает его.

Практический пример:

Например, я спросил «как работает perplexity простыми словами»:

Вместо списка сайтов я получил готовый ответ. Это сберегло мне очень много времени. Мне не нужно открывать сайты (хотя при необходимости я могу это сделать). Так же это не нейро-ответ Яндекса, перплексити гораздо умнее (на мой взгляд).

Официальная цена vs «Серый рынок»: в чем подвох?

Официальная подписка Perplexity Pro стоит $20 в месяц (или $200 за год). С ней вы получаете доступ к лучшим нейросетям (GPT-5, Claude 4.5, Grok и т.п.), можете загружать сколько угодно файлов и делать больше запросов.

Но на сайтах типа ggsel.net то же самое предлагают купить за 500 рублей в год. Как так? Не понятно… Я так и не понял, но в личном кабинете указана цена подписки как $0 и все регистрируется на мою почту официально и на год. Возможно, какие-то акции самого перплексити, но это — большой вопрос конечно. В чем подвох я так и не понял.

Мой опыт и минусы Perplexity

Я рискнул и три недели назад купил такой доступ для простых личных дел. Пока всё работает хорошо. К удобству быстро привыкаешь: искать сведения для блога или узнавать о новых технологиях стало намного быстрее.

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

С другой стороны, стоит ли это считать минусом?

Выводы

Одно могу сказать точно: Perplexity — это очень мощная и полезная программа, которая может поменять сам подход поиска информации в интернете: то, как мы ищем сведения / факты. А потом это, возможно, может эволюционировать дальше, в персонального помощника.

Что думаете? Кто пробовал Perplexity?

Обработка персональных данных на сайтах. Началось.

Обратил внимание на свежую новость на Хабре.  1 сентября заработали новые положения закона о персональных данных и Роскомнадзор приступил к поиску нарушителей.
Что это? Это предписание исправить на сайте все, что связано с законом, которое заставило меня задуматься. Автор на Хабре подробно разбирает новые требования Роскомнадзора и приводит реальные примеры, когда предприниматели уже получили «письма счастья». Суммы штрафов за повторные нарушения впечатляют, и я решил не откладывать в долгий ящик и провести аудит нашего корпоративного сайта Софтонит.

А самый главный прикол знаете в чем? Скорее всего, все происходит в автоматическом режиме.

Ключевые моменты из статьи на Хабре

Если кратко, то Роскомнадзор теперь уделяет пристальное внимание следующим вещам:

- Активное согласие: Пользователь должен сам поставить галочку в чекбоксе. Предустановленные галочки или пассивное согласие (когда отправка формы автоматически означает согласие) теперь вне закона.
- Четкая политика: На сайте должна быть опубликована «Политика обработки персональных данных», и ссылка на неё должна быть у каждой формы сбора данных.
- Cookies и аналитика: Если используете Яндекс.Метрику или другие счётчики, вы обязаны уведомлять об этом пользователей и получать их согласие.
- Реестр операторов: Все, кто обрабатывает персональные данные, должны быть зарегистрированы в реестре Роскомнадзора.
- Трансграничная передача данных. Это вообще отдельная песня... Используете Google Analytics? Забудьте. Лучше отказаться.

Аудит нашего сайта: что я нашел и исправил

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

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

Проверьте свои формы, наличие правильной политики и активных чекбоксов. Убедитесь, что вы не нарушаете закон.

Йети, который подсматривает ваш пароль. Зачем делать интерфейсы живыми?

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

Вводные
Итак, у нас есть обычная форма входа: логин, пароль и кнопка входа. Функционально, скучно, знакомо. Мы видим такое каждый день и не замечаем. А теперь вообразите, что под полями сидит веселый анимированный персонаж. Например, йети.

Вводим логин
Когда вы печатаете логин, он с интересом водит глазами за курсором. Как только вы начинаете вводить пароль, он в страхе закрывает глаза лапами — секрет есть секрет 🙂 Нажали на значок «показать пароль»? Йети с хитростью приоткрывает один глаз и смотрит. Ввели всё правильно — он рад. Сделали ошибку — он хватается за голову.

Вводим пароль
Это больше, чем веселая игрушка. Это пример дизайна, вызывающего эмоции. Такой подход делает работу с программой и функциональной, и приятной.

Готовые примеры кода есть на Codepen. Это позволяет довольно легко встроить такую функцию в свой веб-проект.

Что это и как устроено?
Эта идея существует давно. Один из хороших примеров — проект «Teddy», который сделал веб-дизайнер Дарин Сенеф. Технически он состоит из трех частей:

1. SVG-анимация: Персонаж нарисован в формате SVG. Поэтому он легкий, меняет размер без потери качества, и его легко анимировать.
2. CSS: Стили делают переходы между состояниями анимации плавными.
3. JavaScript: Скрипт следит за действиями пользователя — выбор поля, ввод букв, нажатие кнопок — и меняет состояние персонажа.

Почему это полезнее, чем просто украшение?

Для руководителя ИТ в разработке любая функция должна иметь цель. Добавление такого персонажа — это не бесполезная трата времени, а шаг, у которого есть несколько задач.

1. Уменьшение стресса и создание контакта
Форма входа может создавать преграду. Пользователь может неверно ввести пароль или логин. Это вызывает небольшое раздражение. Смешная реакция персонажа на ошибку делает этот опыт веселым и снимает напряжение. Пользователь начинает думать, что система дружелюбна. Это первый шаг к построению лояльности.
2. Узнаваемость и отличие от других
Ваш продукт больше не будет «просто еще одним сервисом». Он станет «тем сервисом со смешным йети». Эта деталь запоминается и хорошо отличает вас от конкурентов со стандартными, одинаковыми интерфейсами.
3. Увеличение интереса

Это называется микровзаимодействие. Маленькая, но продуманная реакция программы на действия человека. Такие детали оживляют продукт. Они побуждают пользователя дольше оставаться в программе и изучать её.

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

- Скорость работы. Анимация, если она плохо сделана, может замедлить загрузку страницы входа. Это плохо, потому что скорость важна для хорошего впечатления. Решение: использовать легкий SVG-файл и простой JS-код.
- Уместность. Веселый элемент подходит не для всех продуктов. В программе для банка или управления важной системой он будет выглядеть странно и может снизить доверие. Но для CRM, менеджера задач или сайта компании это хорошее решение.
- Отвлечение. Некоторых пользователей анимация может отвлекать.

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

А вы видели похожие «живые» интерфейсы или какие-то не стандартные приемы шутки на сайтах или в интерфейсах программ? Что вам больше всего запомнилось? Напишите в комментариях!

Как WinRAR пережил эпохи и стал легендой? Продается уже более 30 лет (!)

WinRAR, утилита из Челябинска, уже более 30 лет остается на плаву, пережив бесчисленные технологические тренды. Это не случайность, а результат гениальных решений. Вот его код долголетия в нескольких пунктах:

1. Фокус на продукте, а не на бизнесе. Программист Евгений Рошал полностью сосредоточился на коде, в то время как его брат Александр взял на себя все юридические и коммерческие вопросы. Это позволило десятилетиями улучшать продукт, не отвлекаясь на управление.

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

3. Бизнес-модель, победившая пиратство. Легендарный «бесконечный триал» — это не ошибка, а стратегия. Зачем искать взломанную версию с вирусами, если официальная работает бесплатно? Это создало огромную базу из 500+ млн пользователей и сделало формат .rar стандартом. А деньги приносят корпоративные клиенты, которые по закону обязаны покупать лицензии.

Ключевые уроки от WinRAR:

- Решайте «скучные», но вечные задачи. Управление файлами нужно было вчера и будет нужно завтра.
- Сделайте легальный продукт удобнее пиратского. Лучшая защита — превосходный опыт.
- Эволюция важнее революции. Постоянные, продуманные улучшения создают доверие.
- Знайте свою главную силу. Рошал — кодер. Он не лез в продажи, и это спасло продукт.

WinRAR — это мощное напоминание, что долгосрочный успех строится на качестве и доверии, а не на погоне за хайпом.

PS: Пока готовил статью стало интересно и я увлекшись написал целый лонгрид где много интересных фактов и даже есть мерч с winrar 🙂

Неприятный инцидент в ЦОД с сервером. Монолит - это риск

На днях мы столкнулись с неприятным инцидентом в ЦОД. Один из двух наших физических серверов подхватил зловреда, похожего на шифровальщика. Несмотря на наличие средств защиты (Касперский), компрометация произошла. 😕
К счастью, инцидент был замечен быстро, и фатальных последствий для данных удалось избежать. Но ситуация заставила меня полностью переосмыслить текущий подход к инфраструктуре.

Главный вывод: Монолит — это зло.

До этого момента ключевые сервисы (1С, MS SQL, RDP-сервер для разработчиков) жили на одной физической машине (Сервер 2). ИБ-инцидент наглядно показал: любая проблема на этом хосте — будь то зловред, неудачное обновление ОС или аппаратный сбой — парализует всю работу компании. Это недопустимый бизнес-риск.
Век виртуализации наступил давно, и наша инфраструктура очевидно от него отстала. Пора это исправлять.

Я, хоть и директор, глубоко погружен в технические процессы компании. Я убежден, что, прежде чем нанимать администратора или подрядчика для построения новой архитектуры, я должен сам хорошо понять другие варианты, риски и лучшие практики. Только так можно сформировать грамотное ТЗ и принять правильное решение.

Что мы имеем (Дано):

1. ЦОД
- 4 "белых" IP-адреса.
- Маршрутизатор Mikrotik для управления трафиком.
- Канал 200 Мбит/с.

2. Сервер 1 (Младший хост)
- 1U Supermicro, 2 x Xeon E5-2650 v3.
- 190 ГБ ОЗУ.
- SSD-накопители (2 x 480 ГБ Intel, 1 x 960 ГБ Intel).
- Ранее использовался для демо-сервера 1С, бэкапов с Сервера 2 и тестовых VM.

3. Сервер 2 (Старший хост)
- 2U HPE 10 Gen, 2 x Intel XEON 6248R.
- 512 ГБ ОЗУ.
- Высокопроизводительные накопители (SAS SSD 1.6 ТБ x2, NVMe PCI-E 3.2 ТБ x1).
- Архивные HDD (SAS 16 ТБ x2).
- Ранее нес на себе всю основную нагрузку: 1С, MS SQL, RDP, GitLab, GitLab-раннеры, тестовые Linux-машины.

Для Сервера 2 уже заказан апгрейд, который добавит еще 256 ГБ ОЗУ, пару быстрых SAS SSD PM1643a по 3.84 ТБ и дополнительный HDD Exos на 18 ТБ.
Первый сервер послабее, второй достаточно не плохой. Использовать их как два изолированных "монолита" — преступление.

Постановка задачи: Новая архитектура

Цель — построить отказоустойчивую, безопасную и масштабируемую инфраструктуру, используя имеющееся железо.
Очевидный путь — виртуализация. Но просто разнести сервисы по VM на одном хосте — это полумера, которая не решает проблему отказа самого хоста.
Поэтому я думаю о построении HA-кластера (High Availability) на базе двух этих серверов.
В идеале при падении физического Сервера 2 все его критичные виртуальные машины (1С, SQL, RDP) должны автоматически перезапуститься на Сервере №1 c минимальным простоем.

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

Вопросы к профи

1. Платформа виртуализации
Что выбрать для построения отказоустойчивого кластера на двух нодах?
- Hyper-V: Логичный выбор для Windows. Но как лучше организовать общее хранилище? Использовать Storage Spaces Direct (S2D), связывая две ноды?
- Proxmox: Выглядит очень привлекательно. Open-source, HA-кластер и бэкапы "из коробки", отлично работает с Linux VM (KVM). Насколько он стабилен для высоконагруженных Windows-машин (MS SQL, 1C, RDP)? Кто использует в проде, какие подводные камни?
- VMware vSphere: Вариант серьезно не рассматриваю. Думаю это будет слишком дорого.
2. Сетевая изоляция
Просто разнести сервисы по VM недостаточно. Если зловред попадет в одну VM, он не должен иметь доступ к другим. Я планирую использовать Mikrotik для жесткой сетевой сегментации (VLAN). Какие здесь лучшие практики?
3. Отказоустойчивые бэкапы
Инцидент показал, что бэкапы, лежащие на соседнем сервере в той же сети не панацея. Шифровальщик мог бы добраться и до них. Какой софт используете для бэкапа VM в кластере? Куда лучше всего отправлять третью копию (S3-совместимое облако, съемные диски, другой ЦОД)?

Цель — построить прочный фундамент для ИТ-инфраструктуры, который переживет и сбой железа, и атаку, не останавливая бизнес. Буду благодарен за любой конструктивный совет и обмен реальным опытом.

Почему тимлиды выгорают? Ловушка личной эффективности

Уволился тимлид и я задумался. Как так вышло, что толковый парень просто не вывез и «сгорел» (по его словам). Много думал по этому поводу. Как мне вовремя в будущем отследить это состояние у коллег? Да и у себя, чего уж… И вот что я думаю по этому вопросу.
Любому тимлиду / руководителю ИТ чтобы не продалбывать сроки и не забывать про обещанное нужна самоорганизация. Много задач, разные созвоны, куча договоренностей и без системы устоять нельзя.

Сначала все просто: список дел, приоритеты, план на день. Но потом этого становится мало.
Мы идем дальше: используем GTD, строим базы в Notion, считаем время, вводим утренние правила и смотрим итоги недели. Хочется стать идеальной машиной. Машиной, где запрос клиента сразу становится готовым продуктом. Без опозданий, без ошибок, без стресса.
Но у этой гонки есть не хилый такой итог: требовательность к себе растет очень сильно. Вчера хватало сделать 90% дел, а сегодня злит, если не 100%. Вчера забытое обещание было простительно, ну а сегодня это провал. Ошибка — уже не опыт, а плохой показатель (KPI).
Такая гонка убирает радость от проделанной работы. Нет времени для новых идей, для «просто подумать» или отдохнуть. Вы становитесь системой, которая хорошо решает задачи, но прекращает чувствовать. Как робот.

Вот тут и появляется выгорание. ИТ-специалисты чаще сталкиваются с этим. Лишь 15% тимлидов не сталкивались с выгоранием в прошедшем году.
Это не обычная усталость. Это долгое напряжение из-за внутреннего давления. Давления от того, что надо быть лучшим, чтобы все и везде успеть.

Что делать?

У меня нет универсального рецепта, но есть набор принципов, которые помогают мне (и, надеюсь, помогут коллегам) не превратиться в робота.

- Эффективность — это инструмент, а не цель. Твоя ценность как руководителя — не в числе закрытых задач, а во влиянии на команду и продукт.
- Определи «нижнюю границу». Вместо погони за 100% KPI каждый день, определи достаточный минимум. Сделать его — уже победа. Все, что сверху, — бонус, а не обязательство.
- Легализовать ошибки (для себя и коллег). Пропущенный срок — не провал, а повод для анализа системы. Что в процессе пошло не так? Понятно, что здесь речь не о факапах мирового уровня, но все мы люди и все ошибаемся.
- Планируй «ничегонеделание». Сон и отдых — это база. Но еще нужно время в календаре на «подумать» или «погулять без подкаста». Это не потеря времени, это восстановление ресурсов.
- Говори об этом. Признать, что ты перегружен — не слабость. Это дает и команде право не быть «всегда в форме», снижая общее напряжение.

А вы как с этим справляетесь? Сталкивались с тем, что система личной эффективности начинает работать против вас?
#РазборПродукта_КИД #Кейсы_КИД #Истории_КИД