IT-компании

Проект автоматизации склада согласован. Бюджет выделен. Поставщик решения уже выбран или находится в шорт‑листе. Запуск намечен на следующий квартал. Следующий квартал наступает, и дата сдвигается снова. Потом ещё раз. Потом появляется новый блокирующий фактор, который выглядит абсолютно объективно.

Для этого явления есть название — синдром вечного пилота. Это состояние, при котором WMS, роботизация или другая складская автоматизация формально есть в планах компании, но де‑факто не движется с места уже год, два, три. Склад работает «как всегда»: объёмы растут, персонала не хватает, а стоимость операционных ошибок постепенно становится привычной строкой в P&L.

Привет, Хабр! Меня зовут Надя Скребец, я DevRel СВОЙ Тех.

Обычно здесь рассказывают про архитектурные победы, эпичные факапы или магию Kubernetes. Это круто, но за каждой строчкой кода и каждым релизом стоит человек. Сегодня я хочу показать вам CTO «Свой Банк» — Максима Гречихо.

Для многих позиция технического директора — это вершина карьеры, «финальный босс» в мире ИТ. Но какой вид открывается с этой вершины? Чтобы это выяснить, я буквально зажала Максима в углу между кофемашиной и переговоркой. Бежать ему было некуда, так что я воспользовалась случаем и заставила его поговорить со мной не о графиках и дедлайнах, а о том, почему современный СТО — это больше про смыслы, чем про синтаксис.

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

— Максим, у тебя за плечами 17 лет в ИТ, опыт в гигантах вроде ВТБ и запуск банков с нуля. Ты прошел путь от разработки до управления огромными вертикалями. Расскажи, в какой профессиональной точке ты находишься сейчас и какие планы в новом проекте?

— В данный момент я занимаю позицию технического директора (CTO) в одном из ключевых проектов финтех-группы СВОЙ. Я узнал о группе от коллег и был поражен амбициозными целями банка, культурой компании и ролью ИТ в бизнесе. Желание стать частью такой команды возникло практически мгновенно.

Сейчас в мои обязанности входят управление всей ИТ-командой Банка, взаимодействие и активное участие в развитии бизнеса через наши кроссфункциональные команды, работа с ИТ-бюджетом, ФОТом и КПЭ. Планы у нас достаточно большие: Банк одновременно занят серьезной трансформацией ИТ-ландшафта, внедряя новую АБС и активно реализуя новые бизнес-сервисы. Это накладывает особую ответственность и необходимость очень профессионального подхода к управлению ресурсами, командами и проектами. Так что главный пункт — осуществить задуманное и реализовать все в сроки с нужным качеством. В дальнейшем, конечно, это развитие команды и ИТ-процессов.

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

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

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

В контексте Битрикс24 BI не отдельный внешний инструмент, а логичное продолжение CRM и бизнес‑процессов.

Привет, Хабр! Меня зовут Владислав Шаргин, я — руководитель практики подбора в компании ecom.tech. В этой статье по мотивам доклада для Saint TeamLead Conf я расскажу, как за минимальное количество действий сделать так, чтобы ваш сотрудник был доволен, почему деньги — это не мотиватор, и как правильно задавать вопросы про эффективность. 

Всем привет от Петра Третьяка, который за 10 лет в управлении проектами ни разу не видел, чтобы крупный релиз вышел ровно в ту дату, которую назвали на старте. Ни разу. При этом все на старте в эту дату верили: и заказчик, и команда, и я сам.

В статье рассказываю почему классическая двухдневная стратегическая сессия редко доходит до внедрения, и покажу, как переформатировать её, чтобы стратегия начала работать

Привет всем, я – Соня, IT HRD. Посмотрела большое интервью ex-Amazon VP Ethan Evans про корпоративную политику. Решила с вами поделиться.

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

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

Интервью на 3 часа, ссылку дам в комменте, все заметки делались руками.

1/ Headcount самый простой сигнал лидерства 

Impact субъективен, headcount — нет. Impact сложно оценить. Насколько сложный был проект. Или я работаю в инфре, а ты пилишь revenue-фичи. У кого больше impact? А сколько людей у тебя оценить легко. 

Никто не спорит: у тебя 42 человека, у меня 17. Значит, ты более крупный лидер. 

2/ Если есть метрика — люди начнут под нее играть 

Empire building существует, потому что оно вознаграждается.

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

3/ Для директора в Amazon нужно 80–90 человек

Evans говорит, что для директорского уровня в Amazon сейчас нужно примерно 80–90 человек. Раньше было 22. Чем больше компания, тем выше цифра.

В принципах Amazon записано ‘no bonus for headcount’, но это черт подери не так. У тебя есть огромный бонус в виде должности и зарплаты за хедкаунт.

Седьмой выпуск еженедельных IT-новостей от OpenIDE: Anthropic выносит Claude Code из плана за $20, Duolingo перестаёт следить за потреблением ИИ сотрудниками, а четыре человека из Discord получают доступ к засекреченной модели просто потому, что правильно угадали адрес эндпоинта.

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

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

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

Я проходил через это несколько раз. В такой конфигурации, несмотря на кажущуюся эффективность связки технарь‑идея‑инвестор — ни разу ничего не запустилось. Под катом — четыре паттерна, которые я видел на каждом таком проекте. И как AI может сделать еще хуже.

Управлять тимлидами — это не раздавать задачи и проверять сроки. Это выстраивать среду, где сильные технические лидеры могут проявить себя без микроменеджмента. В статье разберем какие ошибки совершают 90% руководителей, почему контроль убивает инициативу, и как перейти к системному лидерству с помощью OKR, DORA-метрик и роли Delivery Manager. Без воды, с конкретными кейсами и схемами!

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

В Agile и Scrum есть почти священная заповедь: команда должна быть стабильной, долгоживущей. Люди притираются друг к другу, учатся работать вместе, растёт доверие и предсказуемость.

Но вообще, люди уходят, приходят новые, компания растёт, появляются новые продукты, кто-то выгорает, кто-то засиделся и перестал развиваться.

Хайди Хелфанд, автор книги "Dynamic Reteaming: The Art and Wisdom of Changing Teams", проработавшая в AppFolio, ExpertCity и других компаниях, утверждает: изменение состава команды - это не проблема, а нормальный и правильный процесс, которым можно управлять. Она собрала реальные кейсы и показала, что пересборка команд даёт результаты, которых не может дать стабильная команда.

Все промышленные компании, которые разрабатывают программно‑аппаратные комплексы (ПАК), могут получать IT‑льготы.

В этой статье разберём, как это работает, и почему выгодно зайти в реестр ПАК Минцифры уже в этом году.

Две ситуации, знакомые каждому: руководитель сливает ваш проект, а смежники затягивают сервис. Вы пытаетесь «лучше донести» и «проявить эмпатию». Не помогает, потому что дело не в недостатке понимания, а в столкновении KPI, интересов и полномочий. Я собрал фреймворк, который моделирует конфликт как инженерную систему: профиль оппонента, карта власти в компании, сценарии с конкретными фразами и прогнозом реакции. Всё это — диалоги с обычной LLM. Делюсь методом и выкладываю исходники в открытый доступ. Берите. Пользуйтесь. Улучшайте.

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

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

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

Но самое интересное на мой взгляд произошло дальше. Пытаясь разобраться, кто и как организовывает DDoS-атаки в 2026 году, я обнаружил массу специализрованных сервисов: так называемых DDoS-стрессеров — сервисов, где можно запустить атаку на любой ресурс в пару кликов за небольшие деньги.

Пока в мире с такими незаконными сервисами борются, проводя крупные международные операции вроде Operation PowerOFF, в России — из-за необъяснимой лояльности ряда крупных компаний — они чувствуют себя вполне комфортно.

Чем закончилось мое взаимодействие с этими компаниями, предоставляющими инфраструктуру DDoS-стрессерам, в попытке прекратить их работу — вы узнаете в этом материале.

Сколько людей - столько и мнений о процессах в команде (с). 

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

За отправную точку возьмем несколько потребностей: 

• управлять неопределённостью,

• повышать качество требований,

• снижать риски на этапе разработки. 

Поделимся опытом работы в команде разработки продукта электронного документооборота. 

Расскажем о своих решениях, ошибках, находках, и компромиссах и о рабочей модели, которой мы сейчас придерживаемся.

DeepSeek V4 Pro — это 1,6 триллиона параметров, mixture of experts (MoE), 49 млрд активных параметров и контекст в 1 миллион токенов. V4 Flash — рабочая лошадка: 284 млрд параметров суммарно, 13 млрд активных. Обе модели обучены примерно на 33 трлн токенов. На агентских бенчмарках кода, MMLU Pro, GPQA Diamond, SWE-bench Verified — V4 рядом с Opus 4.7 и GPT-5.5. Немного отстаёт, но совсем немного.

Вот в чём дело.

Большинству задач не нужен абсолютный frontier. Компании не решают сложнейшие научные задачи — они ведут бизнес. Представьте: вы CEO, смотрите на GPT-5.5 по $30 за миллион выходных токенов, на Opus 4.7 по похожей цене — и тут DeepSeek в разы дешевле, open source, его можно дообучать, хостить где угодно, контролировать точечно. Математика очевидна.

Здесь и начинается проблема.

Это не про политику. Это про продуктовый сигнал, который считывают все — кроме тех, кто его посылает.

Есть старый принцип в разработке: eat your own dog food — пользуйся тем, что создаёшь. Microsoft внедрила его в 1988-м, когда менеджер написал вирусное письмо коллегам: «Ты ешь свой собственный корм для собак?» Смысл прост — если вы не пользуетесь собственным продуктом, у вас нет мотивации его улучшать. Пользователи это видят. Рынок это чувствует.

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