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