Круговорот

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

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

Уникальность софтостроения как сферы услуг в его высокой кадровой ёмкости. Представьте себе отдел «Х» в управлении крупной фирмы, использовавший для решения какой-то задачи электронные таблицы офисного пакета. На основном производстве тем временем внедрили новую технологию, снизив издержки и сократив несколько работников.

Куда направить освободившиеся ресурсы? А давайте-ка автоматизируем непроизводительную возню отдела «Х» с таблицами, и тогда начальники смогут быстрее получать сводки!

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

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

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

Конкуренция, конечно, формально существует. Но если в производстве она тесно связана со снижением издержек, то в сфере услуг на первый план выходят доверительные отношения между заказчиком и подрядчиком, снижающие риски. Кроме того, проекты нетиповые, заказные, и найти еще одного подрядчика, уже имеющего аналогичный опыт, – это новые затраты и риски. У существующего подрядчика, сопровождающего программы, может быть договор на приоритет новых заказов. Ведь новые программы должны интегрироваться с уже работающими – это опять вопрос отношений с проверенным поставщиком, а попытка сталкивать его лбом с конкурентом может выйти боком вообще всем участникам процесса. Масса скрытых особенностей, непрозрачная среда, полная корпоративных игр и политики. У европейцев есть на сей счёт соответствующая оговорка, что непосредственная власть находится в руках управленцев среднего звена.

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

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

Разница в том, что инфраструктурные услуги неплохо оптимизируются и один бывший администратор сети или баз данных компании может теперь обслуживать сразу несколько клиентов, работая удалённо на прямой связи, а то и непосредственно в ВЦКП^[10] или ЦОД^[11].

В софтостроении такая оптимизация оказывается проблематичной. Кроме упомянутых проблем с конкуренцией, имеет место и другая веская причина – нечёткость требований, сформулировать которые заказчик далеко не всегда в состоянии. Ведь, как вы помните, он уволил своих прикладных программистов ещё 10–15 лет назад. У подрядчика же функциональная специализация программистов существует только для клиентов, способных давать стабильный заказ с высокой долей прибыли. В первую очередь, это банки и финансовые компании. Проектная фирма обычно вкладывает собственные средства в обучение разработчиков предметной области таких заказчиков, вплоть до получения ими второго высшего образования. Найти же программистов, знающих специфику работы отдела «Х» с электронными таблицами, мягко говоря, маловероятно. Подойдёт и бригада после курсов переквалификации, возглавляемая более опытным руководителем, скорее всего, имеющим не техническое, а коммерческо-управленческое образование.

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

Масштабы и последствия

Согласно сведениям IBM, сообщество Java-разработчиков уже к 2006 году насчитывало более 6 миллионов человек^[12]. Вдумайтесь в эту цифру. Шесть миллионов ремесленников ежедневно садятся перед монитором и усердно вбивают в дисковое пространство программный код.

Когда вступают в действие большие числа, впору вспомнить о нормальном распределении, на которое нам открыл глаза ещё старина Гаусс.

Рис. 1. Нормальное распределение уровня профессиональной компетентности программистов

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

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

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

Я не верблюд, чтобы доказывать, что я не верблюд.

Когда выборка составляет 6 миллионов, несложно получить и среднюю по отрасли оплату своего труда. И можно себе представить, скольких усилий стоит добиться высокой оплаты. Не будет иметь большого значения то, что ты можешь сделать хороший дизайн, если за тобой на интервью придёт дилетант, заучивший десять известных работодателю «паттернов», 200 классов фреймворка^[13] и просящий за это в 2 раза меньше денег.

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

Не забывайте, что относительная доля критичных к качеству проектов падает, а переделка работающих систем базового уровня, от которых непосредственно зависит бизнес, – и вовсе редкое явление. Этот момент всегда оттягивают до последнего, предпочитая использовать вышедших на пенсию кобол-программистов и модернизацию мейнфреймов^[14] с помощью специалистов IBM. Слишком высоки риски. Новые значимые проекты возникают только с новыми рынками и направлениями бизнеса.

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

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

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

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

Профориентация

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

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

Во французском языке существует специальный термин «чувство службы» (sens de service). В русском языке также имеется старинное полузабытое слово «услужливый». Чтобы работать софтостроителем в сфере услуг, нужно, простите за тавтологию, уметь быть услужливым. В ещё большей степени «чувство службы» касается консультантов.

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