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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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