В среде 1С распространено такое явление, как позадачное сопровождение. Клиент купил программный продукт 1С, кто-то как-то его внедрил, люди работают. Периодически возникают задачи — ошибки, доработки, консультации. Каждое обращение клиента — задача. Вокруг этих задач всё и вертится.
Позадачное сопровождение — штука непростая и капризная. Несёт в себе массу проблем самого разного характера для всех участников. Вот эти проблемы я и хочу рассмотреть в статье.
Если вы не из 1С, но тоже сопровождаете постоянных клиентов — возможно, вам тоже будет полезно.
Что такое обычное позадачное сопровождение?
Единственный человек, закреплённый за клиентом в позадачном сопровождении — менеджер. На нём лежит вся ответственность за решение задач клиента. Но ответственность, к слову сказать, не полная — менеджер вполне может сказать «я не нашёл специалиста» или «мы не можем решить вашу задачу». Нормально это?
С точки зрения менеджера — да. Да и спецы не против — они вообще не отвечают за благополучие клиента. Руководитель и менеджера, и спецов тоже не возражает — иначе он бы не допускал таких ситуаций, перестроил бы работу людей. В позадачном сопровождении нормально оставить клиента наедине с его проблемой.
С точки зрения клиента это, конечно, дичь. Клиент, напомню, смотрит на интегратора не как на «решателей задач», а как на компанию, взявшую на себя ответственность за весь контур 1С. Клиент ждёт, что интегратор решит любую задачу или проблему, сам найдёт и привлечёт нужных специалистов, сам будет передавать контекст, управлять работой своих людей и так далее
В большинстве же интеграторов, в нашей индустрии — позадачное сопровождение. Нечто вроде маркетплейса услуг разнорабочих, среди которых попадаются и мастера своего дела. Прошаренные клиенты именно этих мастеров и пытаются выудить.
Я в студенческие годы работал на некоей «бирже» — приходишь с утра в определённое место в центре города, там кучкуются студенты и другие, несколько асоциальные личности. Командует всеми «бригадир» — создатель и держатель «биржи». Приезжают клиенты — либо собственники коттеджей, либо прорабы, либо вполне себе руководители среднего звена из различных организаций. Одному яму надо выкопать, другому — кирпич перетаскать, третьему нужно несколько человек для ночной смены на складе — фуры загружать газировкой.
Разговаривать с клиентом может только «бригадир». Поняв запрос, он оборачивается к толпе, в двух словах передаёт задачу и спрашивает — «кто возьмётся?». Из поднявших руку выбирает исполнителя. Нет рук — клиент уезжает ни с чем. Часть денег забирает себе «бригадир», часть получат исполнители.
Эта история никак не связана с позадачным сопровождением, просто вспомнилась. В «позадачке» как: клиент знает, к кому обращаться за решением задач — к менеджеру. Звонит, пишет, как-то объясняет задачу. Менеджер, в большинстве случаев, по ключевым словам может понять, куда идти дальше и кто нужен («зарплата», «себестоимость», «оборотка», «тормозит», «ЭДО» и так далее). Идёт или к спецам, или к их руководителям, или в «распределительный центр».
Там пересказывает задачу, как понял. У спецов есть шутка на этот счёт — «я скинула всё, что скинула мне». В большинстве случаев из постановки задачи, которую принёс менеджер, мало что понятно. Поэтому спецы очень часто не берутся за задачу, если не знают клиента — говорят «чот муть какая-то». Ещё спрашивают, есть ли у клиента деньги, как у него с принятием работ и так далее. Оценивают риски и косвенные затраты.
Частенько никто не берётся, и менеджер идёт дальше, по отделам. Есть такое понятие — «обезьяна на шее» — задача, обязанность, проблема, которая поручена человеку, и он хочет как можно быстрее на кого-нибудь её пересадить. Главная мотивация — избавиться от обезьяны на шее. Этим менеджер и занимается.
Если никого не нашёл — возвращает обезьяну клиенту. Что тот подумает в этот момент — мы далеко не всегда узнаем. Придёт ли клиент снова — очень не факт, мало кто отслеживает потребление услуг такими вот «наверное обиженными», и тем более — пытается понять, почему так вышло.
Ну а если нашёл-таки менеджер исполнителя, начинается управленческий ад. Про него стоит рассказать отдельно.
Сторона менеджера
Итак, у нас несколько менеджеров, за каждым закреплены клиенты, каждый сам принимает задачи и бегает ищет исполнителя. У нас несколько исполнителей — программистов, аналитиков — которые работают в разных отделах, командах, группах. Соответственно, в цепочке управления появляются несколько начальников программистов.
Допустим, у менеджера в работе 10 задач. Скорее всего, их делают 5 программистов, но в пределе может быть 10. На практике это означает, что менеджер немного работает руководителем десяти программистов. Бывает больше, бывает меньше.
Вопрос первый — как думаете, менеджер владеет навыками управления? Да, понятно, что он не полный цикл управления осуществляет. Но, тем не менее: управление задачами — тема не самая простая, требует достаточно много навыков и знаний. Чтобы было понятно: владеть методом управления «ставить сроки и контролировать» — очень и очень недостаточно.
Вопрос второй — как менеджер справится с управлением людьми в разных отделах? В каждой избушке — свои погремушки, так как методы управления в каждом отделе — уникальны. Менеджеру нужно уметь подстроиться или подстроить — никакой отдел не будет создавать «удобный сервис единого окна», куда менеджер просто закидывает задачу и потом забирает результат. Чтобы эффективно управлять в такой конфигурации (исполнители — в разных отделах), нужно обладать очень серьёзной управленческой подготовкой.
Вопрос третий — что менеджер будет делать при возникновении проблем и коллизий? Программист-исполнитель заболел, его коллеги не могут подхватить задачу — что сделает менеджер? Сам найдёт исполнителя в другом отделе? Пойдёт ныть к начальнику больного? Эскалирует сразу выше, мол «мне тут ресурс не предоставляют»? Понятно, что какие-то действия менеджер предпримет, но вы уже поняли, с какой стороны я смотрю — здесь ведь навыки антикризисного менеджмента требуются, и иногда — весьма серьёзные, так как высоки и риски, и их последствия (например, при сдаче клиентом отчётности, остановке работы розничного магазина и так далее).
Я управлением давно занимаюсь, и могу вам честно сказать: менеджер должен быть не семи, а восьми пядей во лбу, чтобы эффективно управлять в таких условиях. Акцентирую внимание — эффективно управлять. Не абы как, через жопу-пень-колоду-не-пришей-кобыле-хвост, а эффективно. Чтобы и задачи решились, и клиенты не отвалились, и программисты не разбежались.
Особая форма усложнения с профессиональной управленческой точки зрения — постоянная смена состава подчинённых. Адски тяжело управлять людьми, которых едва знаешь, никак не влияешь на мотивацию и карьеру, и, не будем забывать — никакой власти у менеджера над программистом нет вообще. Всё управление строится на софтскиллах.
Наверное, мысль моя понятна. Но давайте я её просто напишу: все менеджеры, работающие в позадачном сопровождении, чертовски неэффективны. Любой человек, который в таких условиях эффективен, не задержится на должности менеджера по сопровождению, потому что он — сраный гений управления.
Сторона спеца
Со стороны спеца всё выглядит ещё хуже, чем у менеджера — того хоть с какой-то удивительной натяжкой можно назвать руководителем, он ведь бегает между десятком людей, даёт им задачи, контролирует исполнение, ногой топает (приоритеты меняет). У спеца же в такой конфигурации, как позадачное сопровождение, руководителя нет вообще.
От какого количества менеджеров у спеца задачи — столько у него и начальников. Это, скажем так, активные начальники, «on air». А все остальные менеджеры, с которыми спец работает, но конкретно сейчас от них нет задач — его начальники? Конечно. Потому что могут в любой момент прийти и осуществить какой-нибудь акт управления, прошу прощения. Как минимум — спросить что-то за ранее сделанную задачу (раз делал когда-то задачу, денежку получил — у менеджера есть формальное право тебя тыркать). Также, могут принести новые задачи, взяв тем самым программиста в своё управление.
У каждого менеджера — свой стиль «управления». Один скинул задачу и забыл. Второй раз в день будет узнавать статус. Третий на звонок клиента с вопросом о судьбе задачи ответит «всё в порядке, я контролирую». Четвёртый после аналогичного звонка побежит к программисту и скажет (громко) «с меня клиент требует подробностей, сроков, предоставь их мне!». Пятый не погнушается дать задачу сразу двум программистам, независимо друг от друга, чтобы потом «выбрать лучшее решение» (оправдается заботой о качестве и собственной статистикой «всё равно половина программистов не доделают и бросят»). Шестой заберёт задачу, если ему покажется, что программист не справляется (он же владелец клиента и всего, что тот даёт — прям как кот Матроскин со своей коровой и телёнком).
А способы и инструменты управления, включая коммуникацию, насколько разнообразны? Одни менеджеры «управляют» через мессенджеры. Другие пишут в почту. Третьи приходят пешком и стоят над душой. Четвертые названивают. Пятые назначают в календарь созвон («у тебя же там свободно»). Шестые общаются через руководителя спеца. Седьмые — через своего руководителя 😊. Восьмые просят записывать задачу и отмечать статусы в какой-то своей системе. А ещё есть разные таск-трекеры…
Картина немного гиперболизированная, но не радикально. В реальности спецы просто не выдерживают такой работы, и сознательно сокращают список менеджеров, с которыми работают. Выстраивается скрытая (от внешнего потребителя) маленькая социальная сеть — кто с кем дружит, враждует, презирает, избегает, старается не связываться, делает в последнюю очередь и так далее. Потому что иначе спецу просто не выжить.
В итоге, если попробовать ответить на вопрос «а как и кем управляется отдел программистов?», в позадачном сопровождении получится «как попало кем попало». Если дать более точный ответ, то процессов управления, решения задач — больше, чем программистов в отделе, так как отдельный процесс можно нарисовать по каждому сочетанию спец+менеджер. Если у нас 8 программистов и 10 менеджеров, то в пределе мы имеем 80 схем управления и решения задач.
Кто и как, находясь в здравом уме, сможет хоть как-то гарантировать качество управления и решения задач в такой системе? Никто. Да никто и не пытается. Все приспосабливаются и как-то выживают.
Получается некий свободный рынок в миниатюре, где каждый программист — отдельная организация, и каждый менеджер — отдельная организация, живут они согласно рыночным законам, ничего друг другу не должны, и выживает сильнейший.
А сколько не выживает? Мы с вами — люди серьёзные, и про ошибку выжившего знаем. Если хочешь нормально понять какую-то систему или процесс, суди не только по тем, кто выжил. Посмотри на тех, кто ушёл.
Если хотите узнать реальность, сходите на hh.ru и почитайте отзывы уволившихся — как спецов, так и менеджеров. В 90% отзывов написано — «наладить взаимодействие между отделами». Люди не выживают в таком управленческом аду, как позадачное сопровождение.
Сторона руководителя
В позадачном сопровождении много менеджеров, по-другому никак. Кто-то должен выполнять роль координаторов, принимать и передавать дальше задачи и так далее
Много менеджеров — это много затрат. Разделим на прямые и косвенные.
Прямые затраты — это зарплата менеджеров и их руководителей. Да, знаю, в зарплате менеджера основная часть — это процент, и его кому-то всё равно придётся заплатить, хоть одному менеджеру, хоть десяти (с одной и той же клиентской базы).
Но есть и оклад. Добавим к нему налоги (на оклад) и отпускные. Не забудем про зарплату руководителя менеджеров — если их несколько, без начальника не обойтись. Если менеджеров много, может добавиться административный персонал, который оказывает внутренние услуги. Не забываем про налоги и отпускные всей это братии.
Но важнее косвенные затраты — потери от сложности управления и взаимодействия. Чем больше людей, тем дороже управление. Каждый менеджер сопровождения, по природе своей — маленький царёк (или царицка 😊), который обязательно, безотлагательно и неумолимо выстраивает собственный маленький мирок, свою систему управления.
Каждое маленькое царство-государство увеличивает энтропию общей системы. Проще говоря, добавляет хаоса и неопределённости. Мы про это уже говорили в главах про ад позадачного сопровождения, теперь переводим всё это в затраты и деньги.
Если у нас много менеджеров, с собственными системами управления, к ним приспосабливаются программисты, тоже выстраивая собственные системы — и вуаля, мы имеем совершенно неуправляемый бардак.
Руководитель этого бардака не может им управлять. В его силах — лишь приглядывать, реагируя на острые кризисы и конфликты. Это несложно проверить, если вы руководитель: отдайте любой системный приказ, вроде «с этого дня вот этот процесс делаем вот так».
Ваш приказ утонет в реальности. Вам скажут «Вася так работать отказывается», «а с этим клиентом так не получится», «а мне некогда сейчас этим заниматься» и так далее. Нахер вас пошлют, короче.
Приказ разбился о реальность, которая вам не принадлежит. Вы не руководитель, а пастух чужого стада. Продолжайте просто присматривать и реагировать на острые кризисы.
Косвенные затраты — это потери от неэффективности бардака.
Вы платите за то, что задачи ставятся и распределяются не за секунды, а за часы и дни. За ваш счёт задачу читает не один человек, а цепочка программистов (и каждый, кроме крайнего, говорит «не возьму»). Вы теряете деньги потому, что для смены исполнителя надо побегать, попрыгать и покричать.
Вы даже не замечаете, сколько теряете денег на нерешённых задачах, которые никто не взял или клиенту втихаря сказали «мы не можем решить эту задачу». Гляньте на любого менеджера, бегущего по коридору — пробежка за ваш счёт. Посмотрите на все заседания в переговорках — большинство из них не нужны, но вы их оплатите.
Платите не напрямую, а косвенно, в этом весь ужас. Это альтернативные издержки, и вы их просто не замечаете.
Такова цена позадачного хаоса для руководителя. Вы одновременно:
-
переплачиваете;
-
теряете деньги;
-
ничем не управляете;
-
ничего не можете изменить.
