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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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