Менеджмент

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

Вы читаете первую статью от имени издательства «БХВ» (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% зрителей, если с этим ничего не делать, и эти зрители перегрузят вам охрану и стюартов на входе, потому что не смогут пройти и будут очень громко кричать.

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

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

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

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

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

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

Но у этой деградации есть естественная причина, и она очень простая. Дело в том, что большинству людей по большому счёту наплевать.

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

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

Собеседования — как очередь в муниципальной больнице: все там были, но мало кто потом вспоминает с теплом.

Кто-то берет «100 каверзных вопросов для собеседования» из интернета, кто-то топит за знание фреймворков, кто-то спрашивает разницу между интерфейсом и абстрактным классом. А потом начинается:

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

Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.