惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

A
About on SuperTechFans
GbyAI
GbyAI
I
InfoQ
C
Cisco Blogs
T
Tor Project blog
NISL@THU
NISL@THU
N
Netflix TechBlog - Medium
C
Cyber Attacks, Cyber Crime and Cyber Security
The Hacker News
The Hacker News
T
The Exploit Database - CXSecurity.com
H
Help Net Security
Cisco Talos Blog
Cisco Talos Blog
The Register - Security
The Register - Security
Microsoft Azure Blog
Microsoft Azure Blog
G
Google Developers Blog
A
Arctic Wolf
Stack Overflow Blog
Stack Overflow Blog
C
CXSECURITY Database RSS Feed - CXSecurity.com
P
Palo Alto Networks Blog
aimingoo的专栏
aimingoo的专栏
Microsoft Security Blog
Microsoft Security Blog
P
Privacy International News Feed
L
LINUX DO - 热门话题
Know Your Adversary
Know Your Adversary
L
LangChain Blog
AWS News Blog
AWS News Blog
Security Latest
Security Latest
T
Threat Research - Cisco Blogs
U
Unit 42
P
Privacy & Cybersecurity Law Blog
Spread Privacy
Spread Privacy
WordPress大学
WordPress大学
Latest news
Latest news
L
Lohrmann on Cybersecurity
小众软件
小众软件
阮一峰的网络日志
阮一峰的网络日志
Simon Willison's Weblog
Simon Willison's Weblog
雷峰网
雷峰网
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Y
Y Combinator Blog
S
SegmentFault 最新的问题
Recent Announcements
Recent Announcements
C
Cybersecurity and Infrastructure Security Agency CISA
Martin Fowler
Martin Fowler
S
Schneier on Security
C
CERT Recently Published Vulnerability Notes
B
Blog
Project Zero
Project Zero
Recorded Future
Recorded Future

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Ад позадачного сопровождения
Иван Белокаменцев · 2026-06-25 · via Все публикации подряд на Хабре

Ад позадачного сопровождения

9 мин

0

В среде 1С распространено такое явление, как позадачное сопровождение. Клиент купил программный продукт 1С, кто-то как-то его внедрил, люди работают. Периодически возникают задачи – ошибки, доработки, консультации. Каждое обращение клиента – задача. Вокруг этих задач всё и вертится.

Позадачное сопровождение – штука непростая и капризная. Несёт в себе массу проблем самого разного характера для всех участников. Вот эти проблемы я и хочу рассмотреть в статье.

Если вы не из 1С, но тоже сопровождаете постоянных клиентов – возможно, вам тоже будет полезно.

Что такое обычное позадачное сопровождение?

Единственный человек, закреплённый за клиентом в позадачном сопровождении – менеджер. На нём лежит вся ответственность за решение задач клиента. Но ответственность, к слову сказать, не полная – менеджер вполне может сказать «я не нашёл специалиста» или «мы не можем решить вашу задачу». Нормально это?

С точки зрения менеджера – да. Да и спецы не против – они вообще не отвечают за благополучие клиента. Руководитель и менеджера, и спецов тоже не возражает – иначе он бы не допускал таких ситуаций, перестроил бы работу людей. В позадачном сопровождении нормально оставить клиента наедине с его проблемой.

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

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

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

Разговаривать с клиентом может только «бригадир». Поняв запрос, он оборачивается к толпе, в двух словах передаёт задачу и спрашивает – «кто возьмётся?». Из поднявших руку выбирает исполнителя. Нет рук – клиент уезжает ни с чем. Часть денег забирает себе «бригадир», часть получат исполнители.

Эта история никак не связана с позадачным сопровождением, просто вспомнилась. В «позадачке» как: клиент знает, к кому обращаться за решением задач – к менеджеру. Звонит, пишет, как-то объясняет задачу. Менеджер, в большинстве случаев, по ключевым словам может понять, куда идти дальше и кто нужен («зарплата», «себестоимость», «оборотка», «тормозит», «ЭДО» и т.д.). Идёт или к спецам, или к их руководителям, или в «распределительный центр».

Там пересказывает задачу, как понял. У спецов есть шутка на этот счёт – «я скинула всё, что скинула мне». В большинстве случаев из постановки задачи, которую принёс менеджер, мало что понятно. Поэтому спецы очень часто не берутся за задачу, если не знают клиента – говорят «чот муть какая-то». Ещё спрашивают, есть ли у клиента деньги, как у него с принятием работ и т.д. Оценивают риски и косвенные затраты.

Частенько никто не берётся, и менеджер идёт дальше, по отделам. Есть такое понятие – «обезьяна на шее» - задача, обязанность, проблема, которая поручена человеку, и он хочет как можно быстрее на кого-нибудь её пересадить. Главная мотивация – избавиться от обезьяны на шее. Этим менеджер и занимается.

Если никого не нашёл – возвращает обезьяну клиенту. Что тот подумает в этот момент – мы далеко не всегда узнаем. Придёт ли клиент снова – очень не факт, мало кто отслеживает потребление услуг такими вот «наверное обиженными», и тем более – пытается понять, почему так вышло.

Ну а если нашёл-таки менеджер исполнителя, начинается управленческий ад. Про него стоит рассказать отдельно.

Сторона менеджера

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

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

Вопрос первый – как думаете, менеджер владеет навыками управления? Да, понятно, что он не полный цикл управления осуществляет. Но, тем не менее: управление задачами – тема не самая простая, требует достаточно много навыков и знаний. Чтобы было понятно: владеть методом управления «ставить сроки и контролировать» - очень и очень недостаточно.

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

Вопрос третий – что менеджер будет делать при возникновении проблем и коллизий? Программист-исполнитель заболел, его коллеги не могут подхватить задачу – что сделает менеджер? Сам найдёт исполнителя в другом отделе? Пойдёт ныть к начальнику больного? Эскалирует сразу выше, мол «мне тут ресурс не предоставляют»? Понятно, что какие-то действия менеджер предпримет, но вы уже поняли, с какой стороны я смотрю – здесь ведь навыки антикризисного менеджмента требуются, и иногда – весьма серьёзные, т.к. высоки и риски, и их последствия (например, при сдаче клиентом отчётности, остановке работы розничного магазина и т.д.)

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

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

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

Сторона спеца

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

От какого количества менеджеров у спеца задачи – столько у него и начальников. Это, скажем так, активные начальники, «on air». А все остальные менеджеры, с которыми спец работает, но конкретно сейчас от них нет задач – его начальники? Конечно. Потому что могут в любой момент прийти и осуществить какой-нибудь акт управления, прошу прощения. Как минимум – спросить что-то за ранее сделанную задачу (раз делал когда-то задачу, денежку получил – у менеджера есть формальное право тебя тыркать). Также, могут принести новые задачи, взяв тем самым программиста в своё управление.

У каждого менеджера – свой стиль «управления». Один скинул задачу и забыл. Второй раз в день будет узнавать статус. Третий на звонок клиента с вопросом о судьбе задачи ответит «всё в порядке, я контролирую». Четвёртый после аналогичного звонка побежит к программисту и скажет (громко) «с меня клиент требует подробностей, сроков, предоставь их мне!». Пятый не погнушается дать задачу сразу двум программистам, независимо друг от друга, чтобы потом «выбрать лучшее решение» (оправдается заботой о качестве и собственной статистикой «всё равно половина программистов не доделают и бросят»). Шестой заберёт задачу, если ему покажется, что программист не справляется (он же владелец клиента и всего, что тот даёт – прям как кот Матроскин со своей коровой и телёнком).

А способы и инструменты управления, включая коммуникацию, насколько разнообразны? Одни менеджеры «управляют» через мессенджеры. Другие пишут в почту. Третьи приходят пешком и стоят над душой. Четвертые названивают. Пятые назначают в календарь созвон («у тебя же там свободно»). Шестые общаются через руководителя спеца. Седьмые – через своего руководителя 😊. Восьмые просят записывать задачу и отмечать статусы в какой-то своей системе. А ещё есть разные таск-трекеры…

Картина немного гиперболизированная, но не радикально. В реальности спецы просто не выдерживают такой работы, и сознательно сокращают список менеджеров, с которыми работают. Выстраивается скрытая (от внешнего потребителя) маленькая социальная сеть – кто с кем дружит, враждует, презирает, избегает, старается не связываться, делает в последнюю очередь и т.д. Потому что иначе спецу просто не выжить.

В итоге, если попробовать ответить на вопрос «а как и кем управляется отдел программистов?», в позадачном сопровождении получится «как попало кем попало». Если дать более точный ответ, то процессов управления, решения задач – больше, чем программистов в отделе, т.к. отдельный процесс можно нарисовать по каждому сочетанию спец+менеджер. Если у нас 8 программистов и 10 менеджеров, то в пределе мы имеем 80 схем управления и решения задач.

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

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

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

Если хотите узнать реальность, сходите на hh.ru и почитайте отзывы уволившихся – как спецов, так и менеджеров. В 90% отзывов написано – «наладить взаимодействие между отделами». Люди не выживают в таком управленческом аду, как позадачное сопровождение.

Сторона руководителя

В позадачном сопровождении много менеджеров, по-другому никак. Кто-то должен выполнять роль координаторов, принимать и передавать дальше задачи и т.д.

Много менеджеров – это много затрат. Разделим на прямые и косвенные.

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

Но есть и оклад. Добавим к нему налоги (на оклад) и отпускные. Не забудем про зарплату руководителя менеджеров – если их несколько, без начальника не обойтись. Если менеджеров много, может добавиться административный персонал, который оказывает внутренние услуги. Не забываем про налоги и отпускные всей это братии.

Но важнее косвенные затраты – потери от сложности управления и взаимодействия. Чем больше людей, тем дороже управление. Каждый менеджер сопровождения, по природе своей – маленький царёк (или царицка 😊), который обязательно, безотлагательно и неумолимо выстраивает собственный маленький мирок, свою систему управления.

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

Если у нас много менеджеров, с собственными системами управления, к ним приспосабливаются программисты, тоже выстраивая собственные системы – и вуаля, мы имеем совершенно неуправляемый бардак.

Руководитель этого бардака не может им управлять. В его силах – лишь приглядывать, реагируя на острые кризисы и конфликты. Это несложно проверить, если вы руководитель: отдайте любой системный приказ, вроде «с этого дня вот этот процесс делаем вот так».

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

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

Косвенные затраты – это потери от неэффективности бардака.

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

Вы даже не замечаете, сколько теряете денег на нерешённых задачах, которые никто не взял или клиенту втихаря сказали «мы не можем решить эту задачу». Гляньте на любого менеджера, бегущего по коридору – пробежка за ваш счёт. Посмотрите на все заседания в переговорках – большинство из них не нужны, но вы их оплатите.

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

Такова цена позадачного хаоса для руководителя. Вы одновременно:

 - переплачиваете;

 - теряете деньги;

 - ничем не управляете;

 - ничего не можете изменить.