Кто такие руководители, и зачем они нужны? Какая от них в жизни польза? Чем они вообще занимаются? А чем они должны заниматься?
С одной стороны, традиционно руководитель понимается как тот, кто управляет – строит планы, дает указания, контролирует сроки, орет громче всех, принимает решения и несет за них ответственность.
С другой стороны, есть мнение, что руководитель должен заниматься только развитием вверенного подразделения, не принимая участия в оперативном управлении.
С третьей стороны, есть самоуправление и бирюзовые организации, которые на практике доказали, что такая сущность, как руководитель, не нужна вовсе – это просто набор обязанностей, ролей и контрольных точек, которые легко размазываются между разными людьми.
Так кто же он такой, этот руководитель, и зачем он нужен? Руководитель нужен компании или компания нужна руководителю, как источник дохода? Может, он просто оправдывает свое существование, ведь результат того стоит – доходы руководителей зачастую несопоставимо выше, чем доходы обычных сотрудников.
Я использую специальную модель для оценки руководителей, с которой вам и предлагаю ознакомиться.
Модель
Модель проста до безобразия, но понятна, как правило, только программистам. Но вы ведь – программисты, и вам все будет понятно.
Итак, представьте себе предприятие, автоматизировавшее свой учет в некой информационной системе. И рядом с этой системой сидит программист, всего один. Он и руководитель ИТ-отдела, и кодер, и архитектор – все в одном. Ситуация достаточно распространенная для небольших, а иногда и для больших предприятий – я сам бывал, в течение некоторого времени, единственным программистом на предприятии.
Так вот, теперь представьте, что программист – это руководитель какого-нибудь отдела, а информационная система – это, собственно, его отдел, включая персонал, оборудование, процессы и т.д. И отдел, и служба, и департамент, и все предприятие – это система. И информационная — она тоже система.
Программист волен по-разному обращаться со своей системой – развивать, сопровождать, удалять, ломать, снижать или повышать производительность, заменять на другую, записывать или удалять документы, контролировать остатки и т.д.
Руководитель волен делать со своей системой (отделом) примерно то же самое – развивать, сопровождать, работать в качестве исполнителя, мешать, помогать, разгонять, заменять персонал и т.д.
Модель понятна: отношения руководитель/отдел такие же, как программист/информационная система.
Теперь посмотрим на руководителей через призму этой модели.
Проныра
Самый примитивный тип программиста – тот, который вообще ничего не делает, но как-то умудряется не вылететь с работы. Я лично видел такого – его взяли для перехода с комплексной 1С 7.7 на 1С 8 УПП, а он ни в зуб ногой, ни в первой, ни во второй, но протянул год – только за счет того, что вовремя бегал к генеральному настраивать интернет, аську и скачивать музыку с торрентов.
Другой пример – девушка, которая ничего не умела сама делать, но имела обширную сеть контактов среди программистов и была, как говорят, симпатична и обаятельна, поэтому парни с радостью помогали, полностью решая ее задачи. Причем, парни работали в других компаниях.
Сами понимаете, система при таком программисте живет своей жизнью, практически никак от него не зависит, и от его прихода на должность до ухода в ней не происходит никаких видимых изменений.
Среди руководителей таких ребят тоже полно – что они есть, что их нет. Иногда их называют свадебными генералами, но это в тех случаях, когда руководитель может выполнять хотя бы представительские функции, например — красиво сидеть на встрече с клиентами.
Такие руководители любят всякие мероприятия, совещания – особенно такие, где много народу и открывать рот необязательно. Иногда они бывают настолько убогими, что если им все-таки перепадает задача от руководства, то они не могут даже делегировать ее нормально, потому что система их вообще игнорирует, разве что кто сжалится и поможет.
Говорить о роли такого программиста и такого руководителя в системе и ее развитии смысла нет, т.к. нет ни роли, и развития. Это – самый убогий случай.
Родственник
Это – отдельная разновидность проныр, с разницей в том, что родственникам не приходится особо ничего делать, чтобы на месте остаться. Их туда привели мохнатой лапой, и они сидят. Кто весь день, кто до обеда, кто после обеда, кто дома.
Влияние на систему у родственников уже есть, т.к. их побаиваются – мало ли, какая вожжа под хвост попадет, можно и работы лишиться.
Но по факту, они этим влиянием обычно не пользуются. Быть элементом системы, т.е. выполнять в ней какие-либо функции, не хотят, т.к. появится ответственность и обязательства, хотя бы на работу приходить придется. Развивать систему они не могут, т.к. для этого нужны хоть какие-нибудь компетенции и понимание происходящего.
Бывают, конечно, исключения, когда родственник ведет себя не как родственник, но тогда мы торжественно исключим его из этой категории. Иногда родственные связи даже помогают, делая человека более ответственным и эффективным, например в семейном бизнесе. Эффективность возрастает потому, что родственник не боится увольнения.
Но в целом, в основной своей массе, такой программист не играет роли в жизни системы, а руководитель – в жизни отдела.
Винтик
Бывает такое, что программист превращается в оператора. Не часто, но бывает.
Только и делает, что выполняет обмены, загружает и выгружает файлы, делает бэкапы, вводит документы, формирует отчеты, делает кой-какой анализ данных и т.д. По сути, просто выполняет работу пользователя. Я в жизни видел такое, когда потихоньку, помаленьку, и превратился программист в бухгалтера.
Если превратился, т.е. перешел в другой отдел и на другую должность – то и хрен с ним, нормальная такая трансформация. Но бывает, что работает оператором, а зовется программистом. Кто он тогда такой, в нашей модели? Просто элемент системы, которой он должен был управлять. Кто в таком случае управляет системой и развивает ее? Никто, пока не придет другой и не заметит, что тут что-то не так.
С руководителями такое бывает сплошь и рядом, особенно с низшим звеном, типа бригадиров, начальников участков, главных сис.админов и т.д. Их должность – формальность, они ничем не управляют и ничего не развивают, работают как все, просто имеют чуток больше обязанностей, вроде походов на оперативки и предоставления табелей.
Никакого влияния на свою систему не имеют ни те, ни другие руководители. Не управляют, не развивают, не отвечают. Система от них не зависит.
Спрут
А вот это – совсем другой случай. Такой программист, хоть и не занимается программированием, но является уникальным по важности элементом системы. Например, он один умеет считать себестоимость и корректировать ее в соответствии со стратегией налогообложения.
По сути, это тот же оператор, только более прошаренный, осознавший свою ценность и успешно ее продающий. Такой программист утверждает, что только он знает, как оформить корректировку записей регистров, чтобы «ничего не слетело». Только он может исправлять минуса в оборотке, чтобы не разъехались субконто. Сами можете продолжить список.
Такой программист является неотъемлемой частью системы, ее узким местом, придатком, который нельзя отрезать. Без него будет кризис, и все, включая его самого, это понимают – на нем все держится. Он принимает решения по оформлению сложных операций, по разруливанию сложных проблем, типа ошибок при выгрузке отчетности и т.д.
Руководителей такого типа – еще больше, чем программистов. Они искусственно и намеренно создают условия, при которых система без них не может просуществовать и одного дня (это хорошо видно, когда они уходят в отпуск). Они все согласовывают, все проверяют, особенно то, что предоставляет «наверх», принимают решение по каждому экземпляру процесса (например, заказу покупателя), ходят на все совещания.
Когда им говорят, что надо делегировать, они ссылаются на занятость – просто некогда сесть и подумать, написать инструкцию и передать дела. Вообще, это их любимая отмазка – занятость, которую они искусственно создали. И еще многозадачность.
Ситуация иногда выглядит комично, особенно когда меняется вышестоящий руководитель и начинает спрашивать нашего ключевого элемента – что ты делаешь? А главное – зачем? Ответ обычно – «так принято», или, если успел свою незаменимость зафиксировать в стандартах предприятия, «так положено». Кем принято, когда принято, зачем принято – ответа либо нет, либо его нельзя произносить, т.к. «эту бессмысленную хрень придумал я» звучит так себе.
И программист, и руководитель постепенно сами начинают верить в свою исключительность. Иногда даже начинают жалеть себя, и требовать жалости от окружающих, или даже индуцировать эту жалость у вышестоящих для повышения своего дохода.
Бывает, что такой ключевой программист или руководитель вносит изменения в систему, т.е. действует на нее благоприятно. Но у него почти всегда отсутствует фокус на избавление системы от самого себя. Например, программист может написать крутую обработку формирования пачек документов, которая избавляет людей от рутинного труда, но пользоваться этой обработкой будет только сам программист. Если его попросят научить кого-то другого, то он найдет кучу отговорок, типа «да там дольше объяснять, давай я сам сделаю лучше».
Аналогично поступают и руководители, затачивая систему под себя. Например, был такой коммерческий директор, который выбил себе условие: давайте мне процент от продаж всего отдела, а я буду распределять премию, как мне заблагорассудится. Сами понимаете, что для продажников становится главным мотивом в работе на такого руководителя – не «больше продавать», а «больше нравиться». Объяснить алгоритм распределения руководитель не сможет, потому что этого алгоритма не существует.
В итоге, что для программиста, что для руководителя итог один: система не может ни существовать, ни развиваться без него.
Перчаточник
Есть такие программисты, которые меняют системы, как перчатки. Они не особо умеют программировать, доводить внедрение до ума, решать мелкие и крупные проблемы пользователей, приносить пользу предприятию.
В любой кризисной ситуации, когда от системы больше вреда, чем пользы, они изрекают: пора переходить на другую систему.
Благо, сейчас с этим проблем нет, особенно с учетом смешения ниш линейки продуктов, той же 1С. Можно с УТ 10.3 перейти на УПП, потом на КА 1, потом на БП 3.0, потом на КА 2, потом на ERP, потом плюнуть на все и внедрять УНФ, потом какое-нибудь извращение вроде УСХП (если отрасль позволяет), потом, что удивительно, вернуться на УПП. Каждый переход – это минимум год. Сами посчитайте, сколько можно продержаться на такой стратегии. Вы встречали таких программистов? Я встречал.
Как выглядит аналогичный руководитель? Он без конца меняет методику, основной подход к управлению. Сегодня он ставит план на месяц, завтра будет ставить план на год, потом перейдет на Agile, потом на ТОС, потом на Lean, потом на 4-4-5, потом на бюджетирование, потом на безбюджетную модель. Это еще неплохо, если руководитель все эти методики знает, хотя бы потренироваться в их применении можно.
Но обычно все прозаичнее – такой руководитель все проблемы решает реструктуризацией. Делает из одного отдела два, потом десять, потом опять один, потом набирает новый отдел из новых людей, потом отменяет и рассовывает их по старым отделам, придумывает новые должности и пишет инструкции, процессы и стандарты, или совсем по-детски – меняет подразделения на дивизионы, дивизионы на департаменты, департаменты на команды, команды на дистрикты и т.д.
Суть подхода и у программиста, и у руководителя одна: пока идут масштабные изменения, никто не докопается до результатов. А если докопается, то всегда можно отмазаться: у нас полным ходом идут изменения, сейчас просто невозможно ответить на ваш вопрос, подойдите через месяц, или сами поищите ответ.
Влияние на систему – ужасающее по масштабам, но бессмысленное по результату и эффективности. Это просто изменения ради изменений, только в колоссальных масштабах.
Что особенно плохо – окружающие привыкают к такому поведению, и постепенно просто забывают, что у этих изменений было начало, и должен быть конец. Забывают цепочку изменений, какая система или методика на какую менялась и зачем. В итоге, можно через некоторое время просто повторять весь круг изменений заново, и никто этого не заметит. Я на практике наблюдал такую картину, и вычислил периодичность цикла – 4 года.
Разумеется, ни о какой пользе для предприятия от таких программиста и руководителя говорить не приходится.
Плюшкин
Плюшкин — это персонаж «Мертвых душ» Гоголя, жадный скупердяй, который тащил и хранил все, что найдет, вплоть до огрызков.
Такие программисты-Плюшкины любят всякие хранилища решений и кода, вроде гита, но используют их не по назначению. Вместо того, чтобы искать там решение своей задачи, они тупо скачивают все, на что хватит емкости диска или денег (для платных решений). Хранят в аккуратных папочках, сортируют, иногда пробуют встроить в свою систему, чтобы показать пользователям или директору, выдав за свое и тем самым оправдать свое существование.
Сами они ничего особо делать не умеют, поэтому использование чужой мелочевки для них — единственный способ для выживания в профессии. На серьезные изменения у них не хватает ни сил, ни компетенций, ни смелости.
Таких Плюшкиных можно узнать, взглянув в интерфейс их системы — он будет пестреть иконками от разнообразных дополнений, смысл которых не будет ясен никому. Всякие панели функций, дублирующие дерево метаданных, универсальные сортировки таблиц, управления обменами в базе, не использующей обмены, куча отчетов, даже для других систем и т.д.
Аналогично ведут себя руководители-Плюшкины. Почитывают блоги, статьи, всякие группы в соц.сетях о том, как небольшими усилиями сделать полезные изменения. Из-за бессистемности в выборе методов, понимании проблем своего отдела и самом внедрении получается у них, обычно, ерунда.
Например, посмотрит Плюшкин по телевизору, что новый молодой губернатор проводит совещания стоя, мол это повышает эффективность — и все, наслаждайтесь, подчиненные. Раньше воду в ступе сидя толкли, теперь стоя будете. Или прочитает очередную лучшую практику, что все сотрудники должны от руки писать отчет за день, мол это не компьютерный копипаст, а настоящие, от души слова — и нате, ежедневные сочинения, минус час от рабочего времени.
Влияние на систему такие программисты и руководители оказывают незначительное, и в основном — вредное, т.к. наполняют ее бессвязным мусором и шумом.
Любитель эскорт-услуг
Есть такие программисты, которые почти всегда, для решения любых мало-мальски сложных задач, зовут аутсорсеров. Проект внедрения системы, запуск новой подсистемы, интеграция с сайтом, разработка нового документа, добавление реквизита — для всего призывается внешний программист(ы).
Есть такие же руководители, лично видел. Нужна система мотивации? Оптимизация бизнес-процессов? Разработка стратегии? Анализ системы управления? Ответ один — ищем внешних специалистов.
Влияние на систему, вроде бы, оказывается, но почти всегда кривое и вредное, т.к. консультант работает только с одной частью мозаики.
Например, делает систему мотивации под кривые процессы. Или пишет стратегию, не учитывая мотивацию к ее выполнению. Или, наше родное — делает автоматизацию снапшота процессов, который теряет актуальность за год до конца проекта, хотя это и не важно, потому что цели и мотивация тоже не учтены.
В итоге — всегда криво, с перекосом в какую-то сторону. И у руководителя, и у программиста. Но главное — их собственная роль в этом процессе развития равна нулю.
Терпила
Это самый распространенный вид программистов — те, кто делают все, что им велят. Соответственно — вносят в систему бессмысленные изменения, отдавая ее, кусок за куском, для реализации чьих-то нездоровых амбиций. Это большинство из нас, чего тут рассказывать.
И руководителей таких — навалом. Это все те, кто подпустил к себе внешних автоматизаторов, внедренцев ИСО 9001, внутренних бюрократов всех мастей, требующих предоставлять кучу отчетов, бумажек, проходить миллионы согласований, учить песни и готовить сценки к корпоративу и т.д. В общем, кто открыл часть своей системы для внешнего посягательства, как подъезд для бомжей, и теперь не знает, как их оттуда выгнать, чтобы все это не нюхать.
В итоге, как информационная система, так и система управления отделом или предприятием, становится как заторможенный Франкенштейн, не способный и шагу ступить.
Такие люди – вредители, т.к. под прикрытием «а я чё, мне велели» губят свои системы.
Нормальные
Есть на свете и нормальные программисты, которые сами решают, что делать с системой, зная стоящие перед ней цели. Если цели ставятся кривые, то они не стесняются, и корректируют их, и всем удается договориться.
Есть и руководители нормальные, которые постоянно занимаются повышением эффективности своей системы, и делают это вдумчиво, последовательно, и профессионально.
Ни те, ни другие не встают внутрь системы, кроме совсем экстренных случаев.
Ни те, ни другие не завязывают систему на себя, и в любой момент могут уйти, а система продолжит работать, хоть и перестанет развиваться.
Единственная проблема – ни тех, ни других не существует.
Ключевая проблема
Есть знания, опыт, компетенции, разбросанные по разным людям, которые никогда не могут договориться. Одни умеют делать системы мотивации, другие стратегию, третьи цели и показатели, четвертые автоматизацию, пятые системы управления. Но они никогда не работают вместе и одновременно.
Развитие всегда идет последовательно, вы можете это увидеть по проектам, которые иногда затеваются в компаниях.
Например, внедряется система мотивации, основанная на текущих процессах. Если видно, что процессы кривые, то это игнорируется, чтобы не выходить за масштаб и бюджет проекта.
Или затевается оптимизация процессов, но за ней не поспевает автоматизация, в результате чего получается страшный гибрид из новой и старой версии того и другого.
Про автоматизацию уже много раз говорил, особенно внешнюю, силами аутсорсеров. Они просто делают автоматизированный слепок бессмысленных процессов, немотивирующей мотивации, неизмеримых целей и без системы управления вообще.
Получаются бесконечные гонки – каждая часть системы поочередно вырывается вперед, чем только усугубляет состояние всей совокупности.
Решение
Решение простое до безобразия – интегрировать развитие. Менять одновременно все части системы, чтобы между ними не было дисбаланса.
Потому что основную проблему несет дисбаланс, несоответствие частей системы друг другу. Хотя кажется, что проблема в какой-то конкретной части.
Например, очень часто валят на автоматизацию – она во всем виновата.
Мы, программисты, обычно валим на процессы, мол там бардак, а нас заставляют его автоматизировать.
Внедренцы систем мотивации жалуются и на процессы, и на неавтоматизированные показатели, и на отсутствие целей. И т.д.
Но настоящая проблема – в дисбалансе, который создает гонки развития, и компания никогда не получает преимуществ каждой части бизнес-системы.
Внедряет ERP, и пользуется 10 % возможностей, потому что под остальные нет процессов. Внедряет систему грейдов и не пользуется, потому что не автоматизирован расчет показателей. Пишет стратегические цели, но никогда их не достигнет, потому что процессы не перестроены соответствующим образом.
Суть одна: каждая часть, сама по себе, неплоха, но все вместе они не работают, потому что находятся в дисбалансе.
Вернемся к руководителям и программистам
Модель, которую я рассказал вам – не для того, чтобы просто посмеяться. Она – для понимания ситуации в конкретном месте, на конкретном предприятии, с конкретным руководителем.
Аналогию с программистом я выбрал по одной простой причине – я сам программист, и вы – программисты. Наверняка, если объяснять роль и влияние руководителей девушкам из HR, придется придумывать другую модель. Потому что мысль, которую я хочу донести, одна, а моделей может быть много – они лишь для удобства понимания.
Но, как мне кажется, руководители – это атавизм. Бизнесу они не нужны. Они как вредная привычка, которую ненавидишь, но боишься бросить. Руководители создают иллюзию опоры, стабильности, управляемости бизнеса. Они, вроде как, «несут ответственность», «принимают решения», «координируют» и тому подобные, ничего на деле не значащие слова.
Все эти слова придумали сами руководители. Попробуйте, шутки ради, убедить руководителя, что он не нужен. Он вам столько всего нарассказывает, как без него будет плохо, что уши повянут. Но слушать самого руководителя о том, зачем он нужен бизнесу – все равно, что спросить у приговоренного к расстрелу, зачем тому жить.
Модель сравнения руководителя с программистом, я надеюсь, поможет вам, во время такого и подобных разговоров, не забыть, зачем вообще нужен руководитель.
Куда ж его девать?
Девать надо не человека, а общепринятую модель руководителя – «большой босс с большой зарплатой». К этому же, на самом деле, стремятся те, кто хочет стать руководителем?
Хороший ответ дает модель Белбина. Обычный руководитель – это неопределенный компот из неясных обязанностей, который нужно просто разложить по полочкам ролей, и для конкретного человека подобрать подходящую работу.
Умеешь координировать действия людей в оперативном режиме? Ок, будь координатором.
Умеешь вдохновить, поддержать, двинуть дело вперед? Ок, будь мотиватором.
Умеешь доводить проекты до конца в короткие сроки? Ок, будь финишером.
Имеешь видение, знаешь куда идти, можешь предложить правильные идеи? Ок, будь генератором.
Умеешь анализировать, держать в уме много параметров системы и понимать ее уязвимости? Ок, будь аналитиком.
Все эти роли – не руководство. Это просто роли, работа такая.
Если ты говоришь людям, что им делать, это не значит, что ты главный. Диспетчер тоже говорит таксистам, куда ехать. Не говорит, говорил. Его же заменили системой.
Если ты умеешь вдохновлять людей, это не значит, что ты главный. Кому-то достаточно правильный фильм посмотреть, чтобы вдохновиться, и ты ему нахрен не сдался со своей мотивацией. А кого-то жена дома так вдохновит, что мало не покажется.
Если разложить традиционное «главенство» по полкам ролей и компетенций, то от него ничего не останется. Так зачем нужен такой руководитель? Тем более, при раскладке окажется, что ни одну из ролей он толком выполнять не может.
А король-то голый, как говорилось в сказке.
Автор: Иван Белокаменцев
