Kurgan-Telecom Ru | Информационные технологии

Я думаю, многие айтишники не любят принимать заявки от пользователей по телефону. Многим знакома ситуация, когда служебный телефон находится в режиме «без звука», и только индикатор активности линии выдаёт, что кто‑то пытается дозвониться до IT‑отдела. Или когда айтишники редко находятся на рабочем месте, а координатора в отделе, который бы принимал заявки и передавал их затем своим коллегам, нет. Раздавать свой личный номер всем я, например, не хочу — иначе замучают потом звонками по всякой ерунде.

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

Мы с коллегой долго решали, что всё‑таки использовать для решения задачи сбора заявок от пользователей в нашей небольшой поликлинике. Пробовали различные мощные Service Desk и Help Desk‑системы, даже настроили GLPI — кто не знает, это такой «монстр», который может много: начиная от инвентаризации всех устройств в сети до работы в качестве Service Desk‑системы для сбора заявок от пользователей. Но чтобы настроить шлюз для получения почты, нужно столько лишних движений сделать, что просто диву даёшься, как можно было так «заоверинжинирить» систему, что ею просто не хочется пользоваться. К тому же работа через email — это не то, чего мы хотели. Это сложно и как‑то уж чересчур формализованно.

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

Мы проводим Школу программистов hh уже в 16-й раз. За это время через программу прошли сотни студентов, 115 выпускников в итоге стали частью команды hh и продолжают с нами работать. Формат Школы остается практичным и прозрачным: три месяца теории и четыре месяца командного проекта под руководством наших инженеров — реальная работа над продуктом с ментором из компании, а не сухие учебные примеры.

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

В этой статье я проведу традиционный разбор вступительных заданий в нашу Школы программистов, которая для многих становится реальным шансом попасть в hh.ru.

Человек всю свою история учился справляться со страхом. Сначала он молился богам, потом возводил стены, потом научился считать. Теперь он роет убежища — не в панике, а с расчётом. Девять квадратных метров спасают людей каждый день. Подвал за двадцать тысяч долларов даёт неделю независимости. Люксовый комплекс за десять миллионов пытается решить задачу, которую деньги не могут полностью решить: как остаться человеком, когда ты заперт под землей? Поговорим об инженерии, которая встречается с психологией. И том, как мы считаем риски и покупаем время.

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

Это разбор реального опыта внедрения доступности в крупном веб-продукте с десятками микросервисов и сложным фронтендом. Без лозунгов, зато с кодом, ошибками, переработками дизайн-системы и неожиданными проблемами в CI. Поговорим про ARIA, серверный рендеринг, мобильные скринридеры, автоматическое тестирование и про то, почему доступность — это не про alt у картинок, а про архитектуру.

Когда я впервые услышал фразу сделаем доступность, я честно подумал: окей, добавим alt, поправим контраст, закроем задачу. Спойлер — это был самый наивный момент за весь проект.

Мы работали над крупной B2B-платформой. Много форм, таблиц, кастомных контролов, графиков, drag-and-drop, модалки внутри модалок. И в какой-то момент заказчик сказал: продукт должен соответствовать WCAG 2.1 AA. Причём не формально, а чтобы им реально могли пользоваться люди с ограничениями по зрению и моторике.

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

Давайте по порядку.

Если первая часть моего репортажа по конференции алготрейдеров в Москве была об инфраструктуре, то вторая часть будет про искусственный интеллект.

ИИ в 2026 году это неполноценная замена трейдера — всего лишь промежуточная стадия. Кто‑то видит в нём помощника в предсказаниях движения рынка, кто‑то маркетинговый баннер для привлечения клиентов частных лиц, а кто‑то просто удобный инструмент автоматизации.

Дальше покажу каждую из этих стратегий:

ИИ как исследователь.

ИИ как маркетинговый интерфейс.

ИИ как торговый помощник.

И нигде в докладах не было что — ИИ как гарантированный источник альфы.

Небольшое пояснение — альфа — это доходность сверх рыночной (беты), которую стратегия получает благодаря своему преимуществу: лучшей модели, данным, скорости. Это не «просто прибыль», а прибыль после компенсации за риск. Например: если рынок вырос на 10%, а ваша стратегия — на 15% при том же уровне риска, то ваши +5% — это и есть альфа.

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

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

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

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

Разработка любого ИТ-продукта, если она ведётся осознанно и целенаправленно, а не спонтанно и хаотически, требует чёткой постановки задачи – что должно быть получено в результате. Соответственно, необходимо описание требований к создаваемому продукту, которое и принято называть «ТЗ» – Техническим заданием.

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

Однако, возникает логичный вопрос – ДЛЯ КОГО должно быть написано ТЗ.

Из этого уже вытечет следующий вопрос – ЧТО должно быть включено в ТЗ, т.е. какие требования составляют спецификацию (как, собственно, в иностранных языках ТЗ обычно и называется – «спецификация требований»).

Конечно, можно (и, в большинстве случаев, нужно) использовать существующие стандарты – например, отечественные ГОСТ 19.201 для программы и ГОСТ Р 34.602 для автоматизированной системы. Есть и другие стандарты, которые достаточно хорошо описывают структуру и содержания таких документов. Но увы, в большинстве случаев эти стандарты описывают спецификации «внешних» требований заказчика к целевому продукту (что, в сущности, верно), т.е. продукт рассматривается как «чёрный ящик», который что-то и как-то делает, и вот эти «что-то» и «как-то» в их внешнем проявлении в ТЗ как спецификации требований и описываются. А вот вопрос о том, может ли быть ТЗ «для разработчика», остаётся открытым.

Вы, читатель, как и автор, тоже досадуете, когда в промтах проскакивают досадные опечатки или грамматические конструкции, которые заставляют даже терпеливую LLM «задумчиво» переспрашивать: «What do you mean?»

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

Здравствуйте, дорогие читатели. Хочу поделиться сокровенными знаниями о том, как я довожу до конца большинство запланированных дел. Если быть точным, это мой подход к использованию методов, описанных в книге Atomic Habits. Если вас заинтересует этот пост, всячески советую ее прочитать.

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

Уже вечер, ты активно пишешь код. Тревожность вместе с тобой. Утром на дейли сказал, что добьёшь таску: да она не сложная, каких‑то 2 стори поинта. Но вот вечер, и ты точно не успеваешь. Завтра на дейли спросят статус задачи, а ты — не сделал. Да, ты общался с архитектором по решению, отвечал на вопросы поддержки и помогал решать проблемы с тестовым окружением. Ещё был синк с другой командой, помог решить проблему с локальным окружением другому разработчику и готовил контракт для фронта для будущей таски. И на обед ты не сходил. Но кого это заботит, если твоя задача все ещё в InDev? Точно придётся посидеть ещё пару часов ночью, чтобы закрыть должок.

Или другой вариант. Ты — менеджер. У тебя за день от 5–6 встреч. Всё нужно решить. Ну и текучка не отпускает: нужно решить конфликт в команде «А», есть запрос на согласование обучения для Иванова, нужно ещё согласовать технические работы и выдать пару доступов. А ещё Сергей из команды «B» недостаточно открыто ответил на вопрос своего коллеги, и тут просят твоего внимания. И, кстати, ещё нужно запланировать изменение процесса и предложить расчёт новой метрики.

Знакомо?

Тогда тебе точно нужен курс по time management ряд привычек, которые каждый может внедрить в свою работу.

Мы привыкли думать, что главным узким местом ИТ-разработки является capacity — количество рук, способных перевести бизнес-требования в рабочий код. Долгие годы индустрия строила "фабрики фич" и масштабировала пирамиду разработчиков. Но генеративный ИИ сломал эту физику.

Сегодня производство артефакта (кода, лендинга, дизайна) стремится к нулю по стоимости. Кодинг перестает быть рычагом конкуренции: он коммодитизируется и больше не ограничивает ни рынок, ни организацию. Объем кода и скорость коммитов превращаются в шум — они больше не коррелируют с ценностью продукта.

Если код стал дешевым, куда сместился дефицит? И почему ИИ, способный написать любую систему, никогда не станет в ней полноценным CEO?

Смотрю на вас как в зеркало... но в ответ не тронь, мы не для таких как ты, правда? Да мы не для таких, мы были созданы для настоящих мужиков. Когда одухотворяют неживые вещи для общения с ними это Антропоморфизм, а как называется когда человек с головой другого человека не разговаривает, но одушевляет части его тела, для общения с ними? Хм, ну да ладно от вымысла к реальности, а реальность у нас - 5ая статья в серии Шампур-Скребок выходит в публичное пространство. Route Load bot (телеграмм) для укладки груза.

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

Broadcom купила VMware в конце 2023-го за 61 миллиард и перекроила лицензирование. Рынок зашевелился. Каждый второй вендор выпустил пресс-релиз про «замену VMware». Прошло два года. Полностью мигрировали 4%. Четыре процента. Аналитики прогнозируют, что к 2028-му уйдёт 35% рабочих нагрузок — не компаний, а нагрузок. Большинство организаций, даже уходя, будут жить с VMware на части инфраструктуры ещё годы. Эта статья про то, почему четыре.

Я проектирую и эксплуатирую enterprise-платформы виртуализации и VDI, и мне есть что сказать про то, как оно устроено на самом деле.

Киберспорт - это крупный и растущий рынок, в 2025 году количество россиян, интересующихся киберспортом составило 28,9%. Люди играют в соревновательные игры по разным причинам, среди которых укрепление социальных связей, развлечение, уход от проблем и даже получение ощущения власти. 

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

— Нам нужен дизайн-док. — Какой именно? — Ну...ГДД.

Пожалуй, это одна из самых частых ситуаций, с которыми я столкнулся, начав искать работу в студиях.

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

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

Под «дизайн-доком» может скрываться что угодно: от one-pager на одну страницу до многостраничного системного описания с метриками, балансом и техническими ограничениями.

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

Итак, попробуем разобраться.

Знаете это чувство, когда в конце дня понимаешь, что сделала кучу движений, но результата ноль? Отчеты написаны, письма разосланы, но мозг вытек, потому что 80% времени ушло на копирование, вставку и форматирование.

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

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

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

Представьте огромную библиотеку, где все книги — от кулинарных рецептов до квантовой физики — свалены в одну гигантскую кучу на полу. Чтобы найти книгу «Война и мир», вам придется перерыть весь завал, и высока вероятность, что вы достанете «Войну миров» Герберта Уэллса или методичку «Как сдать мир на войне». Примерно так выглядит глобальное пространство имен в C++ без использования namespace.

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