Хабрахабр

Кровососы. Классификация программиста

Кто такие руководители, и зачем они нужны? Какая от них в жизни польза? Чем они вообще занимаются? А чем они должны заниматься?

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

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

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

Руководитель нужен компании или компания нужна руководителю, как источник дохода? Так кто же он такой, этот руководитель, и зачем он нужен? Может, он просто оправдывает свое существование, ведь результат того стоит – доходы руководителей зачастую несопоставимо выше, чем доходы обычных сотрудников.

Я использую специальную модель для оценки руководителей, с которой вам и предлагаю ознакомиться.

Модель

Модель проста до безобразия, но понятна, как правило, только программистам. Но вы ведь – программисты, и вам все будет понятно.

И рядом с этой системой сидит программист, всего один. Итак, представьте себе предприятие, автоматизировавшее свой учет в некой информационной системе. Ситуация достаточно распространенная для небольших, а иногда и для больших предприятий – я сам бывал, в течение некоторого времени, единственным программистом на предприятии. Он и руководитель ИТ-отдела, и кодер, и архитектор – все в одном.

И отдел, и служба, и департамент, и все предприятие – это система. Так вот, теперь представьте, что программист – это руководитель какого-нибудь отдела, а информационная система – это, собственно, его отдел, включая персонал, оборудование, процессы и т.д. И информационная — она тоже система.

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

Руководитель волен делать со своей системой (отделом) примерно то же самое – развивать, сопровождать, работать в качестве исполнителя, мешать, помогать, разгонять, заменять персонал и т.д.

Модель понятна: отношения руководитель/отдел такие же, как программист/информационная система.

Теперь посмотрим на руководителей через призму этой модели.

Проныра

Самый примитивный тип программиста – тот, который вообще ничего не делает, но как-то умудряется не вылететь с работы. Я лично видел такого – его взяли для перехода с комплексной 1С 7.7 на 1С 8 УПП, а он ни в зуб ногой, ни в первой, ни во второй, но протянул год – только за счет того, что вовремя бегал к генеральному настраивать интернет, аську и скачивать музыку с торрентов.

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

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

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

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

нет ни роли, и развития. Говорить о роли такого программиста и такого руководителя в системе и ее развитии смысла нет, т.к. Это – самый убогий случай.

Родственник

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

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

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

Иногда родственные связи даже помогают, делая человека более ответственным и эффективным, например в семейном бизнесе. Бывают, конечно, исключения, когда родственник ведет себя не как родственник, но тогда мы торжественно исключим его из этой категории. Эффективность возрастает потому, что родственник не боится увольнения.

Но в целом, в основной своей массе, такой программист не играет роли в жизни системы, а руководитель – в жизни отдела.

Винтик

Бывает такое, что программист превращается в оператора. Не часто, но бывает.

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

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

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

Не управляют, не развивают, не отвечают. Никакого влияния на свою систему не имеют ни те, ни другие руководители. Система от них не зависит.

Спрут

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

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

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

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

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

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

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

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

Например, был такой коммерческий директор, который выбил себе условие: давайте мне процент от продаж всего отдела, а я буду распределять премию, как мне заблагорассудится. Аналогично поступают и руководители, затачивая систему под себя. Объяснить алгоритм распределения руководитель не сможет, потому что этого алгоритма не существует. Сами понимаете, что для продажников становится главным мотивом в работе на такого руководителя – не «больше продавать», а «больше нравиться».

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

Перчаточник

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

В любой кризисной ситуации, когда от системы больше вреда, чем пользы, они изрекают: пора переходить на другую систему.

Можно с УТ 10. Благо, сейчас с этим проблем нет, особенно с учетом смешения ниш линейки продуктов, той же 1С. 0, потом на КА 2, потом на ERP, потом плюнуть на все и внедрять УНФ, потом какое-нибудь извращение вроде УСХП (если отрасль позволяет), потом, что удивительно, вернуться на УПП. 3 перейти на УПП, потом на КА 1, потом на БП 3. Сами посчитайте, сколько можно продержаться на такой стратегии. Каждый переход – это минимум год. Я встречал. Вы встречали таких программистов?

Он без конца меняет методику, основной подход к управлению. Как выглядит аналогичный руководитель? Это еще неплохо, если руководитель все эти методики знает, хотя бы потренироваться в их применении можно. Сегодня он ставит план на месяц, завтра будет ставить план на год, потом перейдет на Agile, потом на ТОС, потом на Lean, потом на 4-4-5, потом на бюджетирование, потом на безбюджетную модель.

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

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

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

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

Разумеется, ни о какой пользе для предприятия от таких программиста и руководителя говорить не приходится.

Плюшкин

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

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

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

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

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

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

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

Любитель эскорт-услуг

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

Нужна система мотивации? Есть такие же руководители, лично видел. Разработка стратегии? Оптимизация бизнес-процессов? Ответ один — ищем внешних специалистов. Анализ системы управления?

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

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

И у руководителя, и у программиста. В итоге — всегда криво, с перекосом в какую-то сторону. Но главное — их собственная роль в этом процессе развития равна нулю.

Терпила

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

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

В итоге, как информационная система, так и система управления отделом или предприятием, становится как заторможенный Франкенштейн, не способный и шагу ступить.

под прикрытием «а я чё, мне велели» губят свои системы. Такие люди – вредители, т.к.

Нормальные

Есть на свете и нормальные программисты, которые сами решают, что делать с системой, зная стоящие перед ней цели. Если цели ставятся кривые, то они не стесняются, и корректируют их, и всем удается договориться.

Есть и руководители нормальные, которые постоянно занимаются повышением эффективности своей системы, и делают это вдумчиво, последовательно, и профессионально.

Ни те, ни другие не встают внутрь системы, кроме совсем экстренных случаев.

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

Единственная проблема – ни тех, ни других не существует.

Ключевая проблема

Есть знания, опыт, компетенции, разбросанные по разным людям, которые никогда не могут договориться. Одни умеют делать системы мотивации, другие стратегию, третьи цели и показатели, четвертые автоматизацию, пятые системы управления. Но они никогда не работают вместе и одновременно.

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

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

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

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

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

Решение

Решение простое до безобразия – интегрировать развитие. Менять одновременно все части системы, чтобы между ними не было дисбаланса.

Хотя кажется, что проблема в какой-то конкретной части. Потому что основную проблему несет дисбаланс, несоответствие частей системы друг другу.

Например, очень часто валят на автоматизацию – она во всем виновата.

Мы, программисты, обычно валим на процессы, мол там бардак, а нас заставляют его автоматизировать.

И т.д. Внедренцы систем мотивации жалуются и на процессы, и на неавтоматизированные показатели, и на отсутствие целей.

Но настоящая проблема – в дисбалансе, который создает гонки развития, и компания никогда не получает преимуществ каждой части бизнес-системы.

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

Суть одна: каждая часть, сама по себе, неплоха, но все вместе они не работают, потому что находятся в дисбалансе.

Вернемся к руководителям и программистам

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

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

Бизнесу они не нужны. Но, как мне кажется, руководители – это атавизм. Руководители создают иллюзию опоры, стабильности, управляемости бизнеса. Они как вредная привычка, которую ненавидишь, но боишься бросить. Они, вроде как, «несут ответственность», «принимают решения», «координируют» и тому подобные, ничего на деле не значащие слова.

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

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

Куда ж его девать?

Девать надо не человека, а общепринятую модель руководителя – «большой босс с большой зарплатой». К этому же, на самом деле, стремятся те, кто хочет стать руководителем?

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

Ок, будь координатором. Умеешь координировать действия людей в оперативном режиме?

Ок, будь мотиватором. Умеешь вдохновить, поддержать, двинуть дело вперед?

Ок, будь финишером. Умеешь доводить проекты до конца в короткие сроки?

Ок, будь генератором. Имеешь видение, знаешь куда идти, можешь предложить правильные идеи?

Ок, будь аналитиком. Умеешь анализировать, держать в уме много параметров системы и понимать ее уязвимости?

Это просто роли, работа такая. Все эти роли – не руководство.

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

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

Так зачем нужен такой руководитель? Если разложить традиционное «главенство» по полкам ролей и компетенций, то от него ничего не останется. Тем более, при раскладке окажется, что ни одну из ролей он толком выполнять не может.

А король-то голый, как говорилось в сказке.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть