Издательство БХВ расширяет каталог за пределы классических книг по программированию: новое направление описывают как околоайтишная литература о командах, процессах и управлении работой вокруг технологий. Первой крупной заявкой станет русское издание второго выпуска Team Topologies Мэтью Скелтона и Мануэля Паиса, сообщает Habr / Карьера. Для русскоязычной IT-аудитории это сигнал простой: книжная полка разработчика всё чаще заканчивается не на Python, SQL и Kubernetes, а на вопросе, почему сильная команда внезапно буксует на согласованиях.
В БХВ объясняют запуск нового направления наблюдением из собственной редакционной практики. Издательство давно выпускает техническую литературу по программированию, базам данных, искусственному интеллекту, информационной безопасности и смежным дисциплинам. Но читатели, которые каждый день пишут код, проектируют сервисы или отвечают за инфраструктуру, всё чаще упираются не только в синтаксис и архитектуру. Им приходится разбираться, почему восемь компетентных специалистов могут работать хуже четырёх, почему добавление людей в проект замедляет разработку и почему продакт, архитектор и тимлид вроде бы говорят на одном языке, но слышат разное.
Формально эти темы принято складывать в коробку с надписью «менеджмент» или «soft skills». В БХВ с такой упаковкой явно не до конца согласны. Внутри редакции направление пока иронично называют «околоайтишной литературой», но по сути речь идёт о книгах для людей, которые остаются в технологической среде, хотя их работа уже не сводится к личному участку кода. Это тимлиды, техлиды, архитекторы, продакты, руководители разработки, HR-специалисты в IT и разработчики, которые постепенно становятся точкой сборки для задач, людей и решений.
Главная конкретика на старте — договорённость о выпуске второго издания Team Topologies. Оригинальная книга Мэтью Скелтона и Мануэля Паиса впервые вышла в 2019 году и быстро стала заметной в инженерной среде: её обсуждали не как очередной трактат о лидерстве, а как практическую модель организации технических команд. Центральный вопрос книги звучит болезненно знакомо для любой компании, выросшей быстрее своих процессов: почему несколько хороших команд не превращаются автоматически в хорошую инженерную организацию.
Второе издание для БХВ интересно именно сейчас. За последние годы разработка заметно изменилась: компании активнее внедряют DevOps-практики, распределённые команды стали нормой, продуктовые и платформенные подразделения теснее завязаны друг на друга, а ИИ-инструменты добавили новую скорость и новые ожидания. Но старая проблема никуда не делась: команды по-прежнему застревают в очередях зависимостей, встречах без владельца, спорных границах ответственности и вечном вопросе, кто должен чинить сервис, который важен всем, но формально не принадлежит никому.
По планам издательства, околоайтишная литература не ограничится одной книгой о топологиях команд. В БХВ говорят о будущих изданиях по DevOps, тайм-менеджменту для IT-специалистов, применению ИИ в управлении проектами, особенностям HR в технологических компаниях и другим темам рядом с разработкой. Важная оговорка: издательство не собирается превращаться в поставщика литературы про «успешный успех». Заявленный фильтр — связь с реальной работой технических специалистов и руководителей, а не декоративная наклейка IT на обычную бизнес-книгу.
Для рынка это выглядит логично. Российскому читателю доступны переводы технических книг, но литература о зрелости инженерных организаций, продуктовой работе и управлении командами часто приходит с задержкой или растворяется в общем бизнес-разделе. Между тем карьера в IT всё реже выглядит как прямой маршрут от junior к senior с последующим вечным покоем в IDE. Разработчик начинает участвовать в оценке сроков, объяснять решения смежным командам, менторить новичков, спорить о приоритетах, а иногда и принимать решения, от которых зависит не один модуль, а весь продуктовый контур.
Бизнесу такая полка тоже нужна не из любви к модным терминам. Когда компания растёт, её узким местом часто становится не стек, а взаимодействие: кто принимает решения, как команды обмениваются контекстом, где заканчивается автономия и начинается хаос, почему релиз блокируется не багом, а цепочкой «надо согласовать». Книги уровня Team Topologies полезны тем, что переводят эти разговоры из зоны вкусовщины в более предметную плоскость: типы команд, когнитивная нагрузка, границы ответственности, режимы взаимодействия.
Для разработчиков запуск направления может оказаться даже важнее, чем для менеджеров. В IT до сих пор живуч миф, что «настоящая работа» — это код, а всё вокруг него является шумом. На практике именно вокруг кода часто решается, будет ли продукт развиваться быстро или команда начнёт производить бесконечные статусы, митинги и взаимные уточнения. Хорошая околоайтишная литература способна не превратить инженера в корпоративного оратора, а дать ему язык для нормального разговора о проблемах, которые раньше назывались просто «у нас опять всё сложно».
Самый интересный вопрос теперь не в том, как БХВ назовёт новую серию. Важнее, удастся ли издательству собрать каталог без случайных мотивационных книг и выбрать авторов, которые понимают инженерную реальность изнутри. Если получится, русскоязычный рынок получит не ещё одну полку «про гибкие навыки», а практичный слой литературы для тех, кто уже понял: код работает только внутри людей, команд и процессов, а они компилируются заметно капризнее.