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

В связи с этим новостным фоном можно было бы вспомнить и про больную мозоль выставления избыточных компетенций при найме на простые позиции (для ручного тестирования формочек на сайте ищем сотрудника с высшим техническим, 3мя годами работы, и опытом разработки на питоне и администрирования БД), и про зачастую неразвитую функцию корпоративной архитектуры, которая по идее и должна отвечать за то, что корпоративный ИТ ландшафт не генерирует избыточных затрат. Но осветить все аспекты этих явлений в одной статье тяжело. Поэтому остановлюсь на стоимости принятой методологии разработки.

Речь про продвигаемый последние годы Agile. Да, у него есть свои преимущества — в первую очередь пресловутый time to market. Но не будем забывать, друзья, что у всех Agile фреймворков есть и обратная сторона — существенно более дорогая разработка по сравнению с Waterfall при масштабах компаний больше одной команды. Что характерно на обучениях об этом не говорят. Но если спросить напрямую, все agile коучи, внедрявшие гибкие методологии в компаниях, где я работаю, это подтвердили. Пусть и с кучей оговорок про «скорость» и «перспективность».

О причинах дороговизны Agile можно порассуждать отдельно, вспомнив и про необходимость программирования без глубокой проработки, что явно значит принятие рисков больших затрат на рефакторинг кода, и новые дополнительные роли в ИТ процессе (например скрам мастера), и существенно большие потребности в тестировании и девопсе.

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

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

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