Менеджмент

В современном ИТ сложилась парадоксальная ситуация.

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

Парадокс объясняется просто: в современном ИТ отвратительная организация. Настолько отвратительная, что многих её директоров впору увольнять, потому что именно они отвечают за её значительную часть, но многого не делают.

И получается, что сотрудники постоянно сталкиваются с переработками и избыточным стрессом, паническими релизами и бюрократией, совмещением и размытыми зонами ответственности. И так далее.

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

Даже если они не из ИТ-сферы.

Краткий разбор системных ошибок управления, которые годами тормозят развитие российского бизнеса (и не только в IT) 

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

Айтишники стали новой легендой Патриков. Джуны на S-классе, сеньоры на Бали, миллионеры из 1С: всё звучит красиво, пока не заглянешь в цифры. И мы это сделали.

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

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

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

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

С 1 января 2026 года в России меняются налоговые правила. НДС вырастет с 20% до 22%. Упрощенцы с выручкой от 10 млн рублей начнут платить НДС. Страховые взносы для малого бизнеса вернутся к 30%. Патент для торговли отменят.

Важно: 22 октября 2025 года Госдума приняла в первом чтении законопроект № 1026190-8. Закон ещё не вступил в силу — его направили в Совет Федерации и Президенту. Правки принимают до 10 ноября. Если появятся возражения, будет второе чтение после дедлайна.

Таки подумал и решил удалить основную часть статьи.
Мотивация — думаю, что я уже в достаточной степени (да и не я один, судя по обилию статей по данной теме) привлёк внимание к проблеме. В том числе, надеюсь, дополнительно замотивировал продуктологов и технологов компании Bitrix обратить больше внимание как на продуктовую (в том числе UI/UX), так и на техническую составляющую их продуктов. Которые, будем надеяться, в следующих версиях будут лучше. И у людей будет меньше поводов к разочарованию. Я за то, чтобы не просто гнаться за формальным количеством фич, а вылизывать и доводить до ума основной функционал, чтобы им было пользоваться действительно удобно.

Приветствуем, коллеги!

Вы читаете первую статью от имени издательства «БХВ» (BHV) из Санкт-Петербурга, которое наконец-то решило официально обосноваться на Хабре и попробовать систематизировать нашу работу на этой великолепной платформе, объединив рекламный контент, тизеры и спойлеры в корпблоге. Меня зовут Олег Сивченко, я тружусь в БХВ менеджером проектов в области компьютерной литературы 4+ года, одновременно работаю в редакции Хабра, где веду небесспорный, но очень интересный научно-популярный блог @OlegSivchenko и блог с IT-переводами @Sivchenko_translate Кроме меня в команде БХВ есть ещё один маститый хабровчанин, пишущий под псевдонимом Валентин Холмогоров @Holmogorov — ведущий редактор журнала «Хакер», ранее работавший в отрасли кибербеза, руководил командой технических писателей. Так что, феномен хаброблога и хабрааудитории для нас не в новинку. Далее — немного о нашем издательстве.

Я расскажу вам о своем опыте тимлида командой разработки в крупном банке, где старые управленческие привычки иногда брали верх над здравым смыслом. Это субъективная точка зрения на реальную ситуацию, где я — Д«Артаньян, а все остальные — редиски.

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

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

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

Вы уже слышали истории, как некоторые «особенные» компании регистрируют на себя казалось бы обычные слова, а потом судятся со всеми подряд и требуют миллионные компенсации?

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

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

Я юрист по интеллектуальным правам, патентный поверенный РФ №2151. Давайте расскажу, как сейчас на практике происходят такие истории и на что нужно обращать внимание, чтобы не влететь.

На собеседованиях HR-специалисты часто используют метод STAR. Соискателям его тоже полезно знать: метод помогает структурировать рассказ о себе и понять, что хочет услышать от вас интервьюер. Расскажу, как адаптировать его под себя, чтобы структурировать опыт и подчеркнуть вашу ценность перед нанимающим специалистом и продуктовым менеджером.

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

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

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

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

После очередного звонка с шефом в 22:00 я психанул и написал заявление.

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

Привет! Меня зовут Андрей, я руковожу отделом продуктов клиентской безопасности в Selectel. С 1 марта 2026 года в России начнут действовать новые требования к безопасности AI-систем в госсекторе. ФСТЭК утвердила Приказ №117 — первый документ, который официально регулирует создание и внедрение AI-решений на базе LLM в государственных информационных системах. Под катом разберемся, что изменения значат для рынка и как к ним подготовиться.

Год назад меня назначили лидом в диджитал-агентстве и поставили задачу перевести всю команду в таск-трекер. 

Я пытался навести порядок, но через месяц мы потеряли ключевого клиента из-за бардака в задачах. Крайним оказался я. 

Рассказываю, что пошло не так.

За 20+ лет в разработке я прошёл путь от студента с книгой по C++ до техлида, но понял: управление людьми приносит меньше удовольствия, чем написание кода. Карьерный рост — это не всегда движение вверх по иерархии, иногда стоит выбрать то, что действительно нравится, а в IT можно хорошо зарабатывать просто программируя.

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

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

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

Сперва я расскажу про механизм влияния переработок на каждого отдельно взятого человека.

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

Главная мысль: переработки плодят ещё больше переработок и гробят бизнес.

Обрыв каналов связи, багованный релиз, мискоммуникация… Серия загадочных событий, авантюрный детектив из цикла «Следствие вели…» — нет, не с Леонидом Каневским, и даже не Колобки, а команда разбора инцидентов, или просто Post. 

Хей-хей! Я Юля, и я специалист по сопровождению инцидентов в команде Post департамента SRE (Site Reliability Engineering). Когда я рассказываю своим друзьям, чем я занимаюсь на работе, мне часто говорят, что я работаю в детективном агентстве. 

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

Представьте себе, что вы айтишник, которому достался стадион. 

Ладно, это я, если что, несколько лет назад. Я поломался в хоккее, что поставило крест на спортивной карьере, и вспомнил основную специальность. Через несколько лет стал продавать билеты: сначала — в Балашихе, а потом — в Омске на «Авангард». 

Это нелинейный ад. 

Вот представьте себе: у вас есть стадион на шесть тысяч мест, и вам надо продать билеты. Казалось бы, делов‑то: бек с API на учёт мест, фронт на сайте, в приложении, выгрузка XML дистрибьюторам — и всё. То есть надо задекларировать, какие места есть и почём, — и всё.

Ага, щас!

Сначала — ещё до того, как вы расчертите стадион на схему мест и установите цены — вы с удивлением узнаете, что билеты на этот матч уже продают.

Вы купите один ради интереса — посмотреть, что будет, и вас кинут на 1 000 рублей. Потому что это был фишинговый сайт. Ещё таким же образом кинут примерно 1–5% зрителей, если с этим ничего не делать, и эти зрители перегрузят вам охрану и стюартов на входе, потому что не смогут пройти и будут очень громко кричать.

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

Затем вам нужны места для семей спортсменов, для прессы, для тренерского состава и так далее. Потом это надо состыковать с программой лояльности и учётом парковок.

А после этого приходит финальный босс — чёртовы перекупы. Борьба с ними — это примерно половина сложности продажи билета.

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

Но давайте начнём с самого начала. Итак, вам нужно интегрироваться с турникетами. Зачем? Надо!