Как Греф с программистами боролся
- вторник, 14 июля 2020 г. в 00:32:03
Наверное многие помнят скандальное заявление Грефа о том, что Сбербанку программисты не нужны: “У нас огромное количество программистов, с которыми мы боремся”. Давайте проанализируем откуда такие заявления взялись и чем все это закончилось.
Как-то Петр I заехал к поморам и увидел их корабли. Форма кораблей совсем не походила на все то, что Петр видел во время своей жизни в Голландии. Очень этим опечалился русский император и издал указ: все корабли с поморскими обводами сломать, строить корабли только с голландскими обводами. В итоге, Россия надолго потеряла арктическое судостроение, потому что, как оказалось, обводы поморов позволяли им мореходить в сложной ледовой обстановке. А голландские корабли в те широты просто не совались. (более развернутый комментарий дал aik)
В другой раз Петр увидел на мужике рубашку, из четырех частей сшитую. И повелел он все узкие ткацкие станки сломать и делать отныне только широкие. Откуда русскому царю было знать, что на Руси не производили ткань в крупных мануфактурных цехах, как Голландии, а в убогую русскую избу широкий станок тупо не помещался. В итоге, крупные производители ткани ушли с рынка, а в захолустных селениях указ императора просто засунули … под сукно. А рубашки допетровского покроя шили вплоть до XX века.
И вот эта петровщина до сих пор очень распространена в управлении. В том числе, в такой прогрессивной области как ИТ.
Disclaimer: Я имею крайне опосредованное отношение к Сбербанку вообще, у меня нет никакой инсайдерской информации, все, что здесь обсуждается, взято из открытых источников либо является моими предположениями. Уж тем более я не знаю, как и кто повлиял на высказывания Германа Оскаровича, как принимаются вообще подобные решения или какие были прибыли/убытки в Сбере. Пожалуйста, рассматривайте личность Грефа и Сбербанка вообще в данной статье исключительно как некие фантастические, несуществующие собирательные образы. Здесь Герман Оскарович выбран в качестве собирательного образа исключительно из-за его скандальных заявлений.
В общем, возможно, дело было так. Прознал бессменный президент Сбера, что в “Голландии” есть диковинная штука. Называется BPMS. И позволяет эта штука без участия программиста рисовать бизнес-процессы и из них даже исходный код программ генерировать. И издал наш император президент госкомпании указ, которым обязал все бизнес-процессы в Сбере только на BPMS делать.
В жизни, конечно, такое явление встречается сплошь и рядом. Но все-таки, думаю, что дело было несколько иначе.
Пришел какой-то человек к господину Грефу. Может это был какой-то управленец из Сбера, а может просто торговый агент одной из компаний, продающей BPMS-продукты. Показал, как здорово генерируется код, как дешевый аналитик без дорогого программиста рисует готовый алгоритм обработки заказа. И уже вот он — “Wow!!!”-эффект. В проект вкладываются немалые деньги.
В итоге, что мы имеем. Некий BPMS фреймворк. Аналитики им как не пользовались, так и не пользуются. Им стандартные временные диаграммы привычнее. Разработчики разделились. Одни говорят: “Вау! Здорово! Можно делать код без спрингопомойки”. Другие говорят: “Эта ерунда не дотягивает по функционалу и удобству до тупого классического шаблона разработки Chain of Responsibilities”.
Помимо скудного функционала, этот BPMS генерит код из xml-файла, что приводит к большим проблемам при работе с контролем версий. Например, после сведения двух версий через git, этот фреймворк вполне может просто удалить весь разработанный код и оставить пустую директорию. Ну типа он конфликты разрешить не смог. Красиво все только, когда Грефу показывают без параллельных веток, без нескольких разработчиков, работающих над приложением.
А еще оказалось, что с визуальным дизайнером BPM очень неудобно работать в параллель с той же Idea. Он долго открывается, жрет памяти прорву, приходится переключаться постоянно при разработке между контекстами. Да и вообще, BPMS дает не возможности, а ограничения для разработчика. Там, где можно написать просто:
if (x.isOk() && y.isEmpty())
в BPMS приходится лепить шахматную доску ромбиков в визуалке.
Вот и получилось, что менее профессиональные разработчики с восторгом встретили инструмент, а более подготовленные, которые читали про шаблоны Банды четырех и умеют их применять на практике, очень сильно критиковали этот инструмент. Последних, как вы понимаете, гораздо меньше оказалось.
В целом, я вижу, что BPMS оказался довольно спорным проектом вообще, без применения к какому-то конкретному проекту.
Но это все история. А сейчас давайте разберемся, почему происходят ошибки, приводящие к подобным заявлениям, и как в таких ситуациях поступать более эффективно.
По моему мнению, основные причины подобных ошибок в следующем.
Некомпетентность и ошибки управления — это просто бич всей экономики. Например, должность “владелец продукта” в Agile предполагалась как посредник между реальным заказчиком и командой. Его основная обязанность — ставить исключительно бизнесовые задачи и не вмешивается в процесс разработки. Вы где-то видели такое? По факту ВП в большинстве компаний играет роль абсолютно некомпетентного начальника, который ставит не бизнесовые, а чисто технические задачи, диктует декомпозицию и оценку задач, да и вообще мнит себя наполеоном над командой.
В принципе, все эти вопросы: как правильно прорабатывать идеи типа отказаться от услуг программистов, как строить Agile в команде — это давно известные и избитые темы, которые рассказывают на всех нормальных менеджерских курсах, включая краткие курсы для начинающих стартаперов (См. здесь или здесь ). Очевидно, что подобные заявления о ненужности программистов фантастичны и непрофессиональны. Но прежде всего, они могут свидетельствовать о проблемах в менеджменте организации. Но, если честно, я не видел организаций, в которых бы с менеджментом, да и с профессионализмом вообще было бы все в порядке.
В мире розовых пони, возможно, и можно заставить менеджмент принимать взвешенные бизнесовые решения, а клиентов понимать, что они хотят, но в реальности именно разработчику придется отдуваться как за того парня, который им управляет и получает в 10 раз больше, так и за клиента, которому нужна просто машина (что ты ко мне пристал с вопросами про мощность мотора и цвет?). В конце-концов, фантазии менеджеров и клиентов реализует именно разработчик, и только он может задать все эти вопросы про цвет и количество колес. Этим и отличается квалифицированный разработчик уровня principal/lead от просто прокачанного мидла. Ну а аналитик — это, конечно, полезный человек, который способен несколько разгрузить разраба от текучки, но он вряд ли способен построить серьезную программу на BPM-ках. Нет, я согласен, что в некоторых случаях кодогенерация существенно облегчает жизнь программиста, но не лишает его работы.
В общем, вы увидели, как мы плавно от идеи отказаться от разработчиков перешли к тому, что в реальности все держится именно на разработчике, и инструментом для отказа от программистов сейчас будут пользоваться именно программисты.
В заключении еще раз отмечу. Да, мир несовершенен, проблема дураков и дорог никуда не денется, даже на высшем уровне в стране люди типа Грефа отнюдь не редко делают непрофессиональные высказывания.
Да, есть вполне известные способы эффективного управления разработкой, которые читают в школе чуть ли не детям. Но взрослые дяденьки, к сожалению, не столь компетентны, как школьники.
Последней линией обороны как всегда выступает стрелочник разработчик, который должен воплотить некомпетентные фантазии руководства и заказчиков во что-то работающее. Профессиональный разработчик должен понимать и хитрости менеджмента, и желания заказчика, и контекст задачи, и что подразумевалось, но никто не высказал, но главное — как это все это реализовать на практике.
Поэтому большинство идей отказа от программиста, как правило, заканчивается увеличением нагрузки на программиста.
Желаю вам разумной разработки, коллеги.
PS: Артем Ларин artem_larin дал ссылку на пояснения Г.О. Грефа на свои заявления. Рекомендую посмотреть для полноты картины.