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

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

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

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

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

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

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

    Модель


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

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

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

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

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

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

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

    Проныра


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

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

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

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

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

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

    Родственник


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

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

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

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

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

    Винтик


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

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

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

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

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

    Спрут


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

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

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

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

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

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

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

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

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

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

    Перчаточник


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

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

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

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

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

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

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

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

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

    Плюшкин


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

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

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

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

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

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

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

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


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

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

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

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

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

    Терпила


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

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

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

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

    Нормальные


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

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

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

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

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

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


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

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

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

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

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

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

    Решение


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

    А король-то голый, как говорилось в сказке.
    Support the author
    Share post

    Comments 29

      –6
      Статья оочень понравилась. Причем все по делу
        +1

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

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

          Это красиво звучит до тех пор, пока всё хорошо. А в случае форс-мажора кто будет решать, что делать? Все финишёры-мотиваторы отработали, как могли (ну или им так кажется), но что-то всё равно пошло не так: сроки срываются, ТЗ не выполняется… «Большой босс с большой зарплатой» в такой ситуации чётко понимает, что исполнителям-то ничего не будет (ну премии лишат), а вот он рискует очень сильно. И начинает разруливать ситуацию: вызвать кого-то сверхурочно? выдать люлей? привлечь аутсорс? надавить личными связями и подвинуть сроки?
          В общем, веду к тому, что руководство включает в себя ответственность. А по вашей схеме получается, как у Райкина с костюмом: «Кто шил костюм?!»
            –1
            А как называется такой тип руководителя? Сначала он видит, как появляется чиряк на его жопе, потом внимательно наблюдает за тем, как он растет; вместо того, чтобы вовремя смазать зеленкой — всячески игнорирует меры по его нагноению; и только когда чирь достигает гиганских размеров, он почему-то объявляет эту ситуацию форс-мажором, сродни подению гиганского метиорита, случайно залетевшего с просторов вселенной в его маленькую и уютную солнечную систему, берет в руки скальпель и со всей ответственностью, максимально демонстративно, начинает с этой заразой героически бороться.
              0

              Это про идеальный мир, в котором можно вернуться в прошлое и предотвратить все проблемы. :)


              А в реальности — все немного по другому: форс-мажор уже есть, и нужно с ним что-то делать. Как быть теперь?

              +1
              Проблема в том, что ВСЕ руководители, с которыми Я ЛИЧНО работал, в случае форс-мажора валили всё на подчинённых и прикрывались «у меня лапки». Либо второй вариант, решение в лоб: меньше кормить и больше доить. Согласитесь, для принятия такого «умного» решения не нужно особых умений.
              UPD: Это, кстати, тоже может быть не руководитель, а кризис-менеджер. Ну, как МЧС.
              +1
              Есть на свете и нормальные программисты, которые сами решают, что делать с системой, зная стоящие перед ней цели. Если цели ставятся кривые, то они не стесняются, и корректируют их, и всем удается договориться.


              А знаете, бывает такая ситуация, когда программист делает что-то для изделия. А изделие — это сложная аппаратно-программная игрушка. И вот если на этапе разработки аппаратной части «специалисты» (инженера-программиста-электроника, к слову, забыли позвать на обсуждение концепций и схемотехники — он впервые «познакомится» с изделием немного позже — в виде сюрприза) сделали её так, что мысль, как к ней писать программную часть с заявленным функционалом теряется в туманной дали (ввиду большой переусложнённости на данной аппаратной части или вообще практической невозможности достичь требуемого функционала на ней), то вот хоть лопни, а убедить переделать (даже если знаете, как) не получится. Почему? Потому что:
              1) Уже были потрачены деньги. Хорошие такие деньги. Переделка влетит в копеечку.
              2) Уже были потрачены деньги на доработки. Которые по мелочи. Главного они не меняют — см. пункт 1.
              3) Начальство не понимает ни в конструировании, ни в электронике, ни в ПО. Но уверено, что его видение правильное, а остальные просто не умеют работать. Кстати, «специалистов» нашло само начальство без вашего участия. Поэтому объяснить, почему программа с полной функциональностью вырождается в неуправляемого монстра не получится. Начальство хочет знать, мы можем отработать прямую ветку без сбоев? Можем? Ну и отлично. Работа системы резервирования (а именно там и кроется источник серьёзных проблем) и тому подобное не столь важна в глазах начальства. А переделка см. пункт 1.
              4) Главный начальник любитель чайка-менеджмента. Он предпочитает собирать медальки «за службу и верность», а не организовывать работы. Ответственность же всегда будет спихнута ниже («Они, сволочи, меня подвели!»). И ему за это не будет ничего. А нам будет. :)

              :)
                0
                Не подскажите название организации, в которой так работа организована? А то уж больно знакомо звучит :D
                  0
                  Одно из предприятий ВПК в СПб. Лучше не буду называть конкретно. :) Но, думаю, таких контор много будет.
                    0
                    Вот не знаю про СПб, но еще одну такую знаю точно. Не буду говорить откуда — у нас она в городе более-менее сносная одна :)) Коммент точный.
                0
                Спасибо, но я бы сначала себе четко сформулировал определение терминов «Программист» и «Руководитель» с целью увидеть не только сходство, но и их различия, чтобы Ваша (Белбина) модель не вводила в заблуждение, как несовместимая смесь Социальной и Программной инженерий, иначе, например, найдя сходство «Программист» и «Композитор», кто-нибудь другой, с потугой абстрагировавшись от оркестра до IT-отдела, предложит модель, где главное типа как сесть, а не дирижер.
                  +2
                  Что-то много статей о плохих программистах и руководителях. Давайте уже о хороших, ато уже забываю, как хорошие выглядят, рябит от разных сортов плохих.
                    0
                    Много написано, правдоподобно, но замени программист на любую другую профессию и вроде бы смысл не потеряется. Про программистов ли статья или это частный случай?
                      +5
                      Я один не люблю стереотипов и навешивание ярлыков? Ещё и с художественными названиями. В разных сферах разный темп работы и разные цели. Что хорошо для одних не всегда нужно другим.

                      В «энтерпрайзе» обычно нужно, чтобы системы стабильно работали и программист умел вносить требуемые изменения за вменяемое время. Большего не требуется. Программист не кодит 24/7, а решает задачи по мере их поступления. И код там одноразовый. Это не программист с художественным названием, а потребности такие у работодателя.

                      Естественно в модном стартапе всё по другому. Надо новый, красивый и креативный код писать, всё время в мыле быть. За спиной стоит организатор, который хочет выжать из тебя всё. И ты вынужден скакать сломя голову.

                      Это как бы два экстремума по темпу. Между ними есть разные градации, но сути это не меняет. Во что вляпаешься, под то и адаптируешься. Ты же сам себе не враг и твоя прямая задача минимом работы получать максимум денег. Это единственная цель работы для любого наемного работника, всё остальное надуманное.

                      Если есть психологические барьеры, например считать чужой код дерьмом и желание писать только новый и красивый, тогда волей неволей придется идти туда, где скакать придется быстро и много. А коли ежедневное ковыряние в чьих-то испражнениях десятилетней давности для вас совершенно не пытка, стоит найти место поспокойнее. Везде свои pros&cons.
                        0
                        А у нас на работе был классический Плюшкин. Наш бывший начальник любил хранить старые запчасти, которые теоретически можно было бы применить для ремонта техники. В результате у нас все шкафы были завалены разным мусором (запчасти для ЕС (которая была демонтирована больше 20 лет назад), материнские платы для процессоров серий 286-486, запчасти для принтеров выпуска начала 90-х, ЭПТ мониторы итп. Также было несколько коробок с отработанными картриджами). Когда уже шкафы не умещали весь этот хлам стали его складывать в коробки и просто складывали их в несколько рядов возле стены.
                        Когда этот начальник от нас уволился мы больше двух недель выбрасывали это «добро».
                          +1
                          Часто стали в последнее время появляться статьи про классификацию…
                            0

                            Спасибо за статью.


                            Егор Бугаенко продвигает идеи


                            • разработки без руководителей и
                            • оплату программистов по факту выполнения задач,

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


                            Вы знакомы с его творчеством (например, методологией разработки и проектом автоматизации разработки ПО)? С Вашей точки зрения, может это работать?

                              0
                              Тема на самом деле не просто не новая, а фундаментальная и касающаяся любой коллективной деятельности.
                              При этом не важно — какова форма собственности предприятия или организации, о каком виде деятельности идет речь — от интеллектуальной или административной и до физического труда включительно, и даже какие век и общественный строй на дворе.
                              Впервые что-то подобное, помнится, я обсуждал со своими старшими друзьями где-то в начале своей трудовой деятельности в самом начале 70-х годов прошлого века. Уверяю вас, что с тех пор в обсуждаемых вопросах принципиально не изменилось ничего.
                              Хотя, как сами понимаете, детали и «декорации» поменялось радикально.
                              Скорее всего, выход из данного тупика лежит в области переоценки роли и, главное, прогрессивного характера коллективной работы как таковой. И вероятнее всего, наиболее понятна необходимость такой переоценки станет в первую очередь именно в сфере IT и в программировании, в частности. Действительно, трудно найти более отличную от работы на хлопковой плантации или на конвейере Генри Форда сферу деятельности — а ведь господствующие и сегодня стереотипы о благотворной и прогрессивной роли коллективного труда сформировались именно еще в те времена…

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

                                  Ну если им вместе с ответственностью деньжат докинут, то почему бы и нет? :)

                                  +1
                                  У некоторых насекомых есть коллективный разум.
                                  Вы надеетесь, что так и у людей?
                                  Описанные Вами модели являются производными от военной. При усложнении внешних условий, описанные Вами модели устремятся к ней.
                                  Если модель управления слегка отлична от военной, значит собственник организации имеет доход превышающий получение необходимого. Если модель управления мимикрировала от военной к странной — собственник «вздыхает по изысканному» и т.д. Как только у собственника припекает, модель управления избавляется от безумных.
                                  «Не мы такие, жизнь такая»
                                    +1
                                    Ни одна «бирюзовая компания/команда» «без руководителя» не сможет: построить БАМ, федеральную трассу, мост через водоём больше ручья. многоквартирное здание. ракету, самолёт вместимостью более 2-4 пассажиров, даже если в этой компании будет супер-пупер финишеры/мотиваторы/координаторы. Для программиста 1С ситуация работа во фрилансе нормальна и в случае обслуживания малого и малосреднего бизнеса нормальная, при росте вся «бирюзовость» испарится в течение 3-4 недель работы. Тот же Сбер, пропагандирующий «бирюзовые отделения» пользуется очень даже не «бирюзовым» АйТи-отделом, обслуживающим эти отделения. А в случае. если вертикаль отлажена, построена и рабоает по жёсткой субординации, строгом регламенте ВСЕХ операций на уровне федерального законодательства и внутренних (о да, бюрократичных) нормативных актах, горизонтальные взаимодействие и свободу отделений на уровне конечных исполнителей и их руководителей самого низкого уровня можно «отбирюзовать» как угодно. Самый вовлечённый, мотивированный и «бирюзовый» оператор/руководитель отделения, «накосячивший» с клиентом или перечислением средств не на тот счёт, тут же отправится искать работу в другом «радужном» банке без права в ближайшей перспективе вернуться под крыло Германа Оскаровича.
                                    Хороший (объективный, а не для рекламы книг Лалу) анализ компания с горизонтальным лидерством в статье от 12.12.2018 в «Российской газете». Там, кстати, и про «чисто бирюзовые» российские компании неплохо написано.))
                                    P.S. Когда исполнитель, никогда не имевший своего дела со штатом исполнителей больше 3-5 человек пишет о том, что «руководители — зло и атавизм» — это настолько занятное и весёлое чтение. Спасибо за хорошее настроение)))))
                                      +2
                                      Дело даже не в конкретном количестве людей, а в том, что на более-менее крупных проектах должен быть кто-то, кто «вотпрямщас» скажет, что делать; кто «мы подумали и я решил»; кто готов подписаться, что Луна твёрдая, и так далее. Вот в чём задача руководителя как явления, а не в мотивации-финишизации. Ну то есть в них тоже, но для этого существуют замы (и вот их как раз заменить/убрать можно).
                                      И немного юмора в тему:
                                      Dilbert
                                      image
                                        0
                                        Насколько я понял, речь шла, скорее, не о том, что «руководители — зло и атавизм», а о многообразии ситуаций, в которых типичные личностные качества и черты характера конкретных руководителей нивелируют любую потенциально-возможную пользу от их наличия в коллективе. Я бы добавил, что приведенный Автором список подобных ситуаций далеко не исчерпывающий. Уверен, что любой способен его продолжить, и как-то для большинства неочевидно мы подошли к такому положению вещей в области руководства подразделениями, что ситуации, отличные от описываемых, вообще стали редкостью.

                                        Про БАМ, раз Вы сами упомянули.)
                                        Я там отработал 10 лет, в основном в БАМтоннельстрое. Как выглядел тоннель на БАМе — естественно, гора, а в ней дыра, рядом — посёлок Тоннельного отряда (организация численностью до 1,5 тыс. человек), с магазином, клубом, школой, стадионом, милицией, баней и т.п. С промзоной — электростациями, мех.цехом, участками Управления механизации, Автобазы, Управления комплектации (отдельные предприятия с базами в других поселках и городах), базами ЖКО и УРС. На ряде самых крупных тоннелей были еще подразделения подрядных организаций — спецшахтуправлений, мехколлон и т.п. Самый маленький поселок — Гоуджекит в лучшие времена доходил до 4-5 тысяч с чадами и домочадцами, самый большой — Северомуйск, до 25 тысяч жителей.
                                        Где-то в 78-м году поступило решение закупить для строительства Северомуйского тоннеля автономный горно-проходческий комплекс американской фирмы Роббинс. Для знакомства с работой которого в Штаты послали группу тоннельщиков, среди которых были мои друзья и родственники. Там их, в том числе, свозили и на реальную рабочую площадку — 3-х киллометровый тоннель на севере Мексики, где аналогичный комлекс эксплуатировался.
                                        Тоннель в Мексике выглядел так — гора, в ней дыра, в дыре горно-проходческий комплекс и рядом с порталом несколько личных трейлеров окрестных фермеров, нанятых и обученных на время строительства тоннеля для работы операторами комплекса в колличестве 16 человек, работавшие посменно вахтовым методом.
                                        Еще пара десятков приезжали на своих и взятых в аренду самосвалах из дома и отвозили породу в отвалы. Всё…
                                        Это я не в критику написанного Вами, а всего-лишь в подтверждение того, что стереотипы в организации труда объективно существуют, и об этом не стоит забывать.)))
                                        +1
                                        Когда-то я думал примерно так же, а сейчас, поработав уже 6-ти разных IT компаниях и на разных позициях, вижу, что работать без руководителей может 5-10% людей. И это в IT компаниях, где люди образованные и более рациональные. Проблемы, при распределении обязанностей, я вижу две. Первая, в том, что мало кто хочет брать на себя дополнительную обязанность и еще меньше, кто готов ее делать также хорошо как свою основную, например, программирование. Вторая, координация между всеми этими ролям и отсутствие понимания или желания понимать бизнес части работы.
                                        При всем уважении к автору, мне кажется, что вам еще есть куда расширять кругозор, хотя бы путем получения опыта работы в разных компаниях(от стартапов до корпорацией) и на разных позициях.
                                        +1

                                        Это ведь уже было на инфостарте. На хабре разрешили перепосты из других мест?

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

                                          Only users with full accounts can post comments. Log in, please.