Текст книги "Дефрагментация мозга. Софтостроение изнутри"

Автор книги: Сергей Тарасов

сообщить о нарушении

Текущая страница: 1 (всего у книги 2 страниц) [доступный отрывок для чтения: 1 страниц]

Сергей Тарасов
Дефрагментация мозга. Софтостроение изнутри

К читателю

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

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

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

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

О нашей профессии

У каждого дела запах особый:

В булочной пахнет тестом и сдобой…

Д. Родари. «Чем пахнут ремёсла?»

Очень краткий экскурс

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

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

Если первые программисты были сильно ограничены в средствах и привязаны к аппаратному обеспечению – «железу», к конкретной ЭВМ [1] , то современные располагают огромным арсеналом инструментов и технологий, в большинстве случаев позволяющих разработчику не принимать во внимание особенности устройства тех компьютеров, на которых его программа будет выполняться.

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

Джордж Лукас приступил к созданию недостающих серий «Звёздных войн» только через 20 лет. Ещё дольше ждали создатели первых луноходов и автоматических межпланетных зондов, прежде чем выпустить на разведку роботы-марсоходы. Станки с ЧПУ [2] , безлюдные заводы и роботы-хирурги не имели практической возможности воплотиться до 1980-х годов, когда появились массовые достаточно мощные промышленные микропроцессоры. Для многих задач и существующая мощность пока недостаточна, поэтому суперкомпьютеры продолжают её наращивать. Но прогнозы погоды всё равно ошибаются.

Специализация

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

Программист = алгоритмизация и кодирование

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

Программист минус алгоритмизация = кодировщик Программист минус кодирование = постановщик задачи

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

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

Тестером (не путайте с тостером) раньше назывался прибор-мультиметр, способный измерять напряжение, силу тока и сопротивление. Вы хотели бы работать «тестером»? А если назвать должность в соответствии с её сутью: «инженер-испытатель»? Думаю, отношение к делу сразу изменится.

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

Кто такой ведущий инженер, или Как это было

Давайте рассмотрим и сравним проектные организации по разработке, поставке и эксплуатации программного обеспечения, оборудования и системной интеграции, условно названные как:

• «А» – организации времён позднего СССР (1960–80 гг.): НИИ [3] , КБ [4] , КТЦ [5] , ВЦ [6] …

• «Б» – современные компании.

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

Иерархия подразделений

(*) – отдел является единицей финансирования, то есть бюджеты составляются, начиная с уровня отдела;

(**) – уровень лаборатории не являлся обязательным для организаций, не ведущих НИР (научно-исследовательскую работу), например для ВЦКП (Вычислительный Центр Коллективного Пользования).

Иерархия должностей

(*) – в современных организациях образовательный ценз, как правило, формально не учитывается;

(**) – как правило, укладывается в шаблон Chief «направление» Officer. Например, CAO – Chief Accounting Officer – главный бухгалтер, CDO – Chief Development Of-ficer – директор по развитию и т. д.

Уровни принятия проектных решений

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

Функциональные специализации (роли)

(*) – как правило, главный конструктор или ГИП занимали должности от начальника сектора и выше в зависимости от проекта, который они возглавляли;

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

Метаморфозы

Упомянутое в предыдущей главе разделение на инженеров и техников существовало с незапамятных времён. Застал я его «живьём» в конце 1980-х – начале 1990-х годов. В штате институтского ВЦ или конструкторско-технологического центра всегда присутствовали «инженер-программист» и «техник-программист». Инженеры имели категории вплоть до «ведущего», что при совмещении руководства группой соответствовало нынешнему словечку «тим лид» ( team lead ). Техники тоже делились по категориям.

Формальное различие состояло в том, что техников готовили в профильных профессионально-технических училищах (ПТУ) и техникумах; их образование называлось средним специальным. Инженеров готовили технические вузы [7] . Наконец, были математики-программисты, которых готовили в университетах.

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

Стандартная должность для программиста-техника называлась «оператор ЭВМ». Некоторое время она сохранялась и после перехода на персональные компьютеры как «оператор ПЭВМ». Потом слово трансформировалась в «эникейщик» (от английского press any key ) и, позднее, «хелпдеск» ( helpdesk ) – специалист службы поддержки пользователей. Соответственно, системный программист-техник большой ЭВМ превратился в системного администратора по эксплуатации сети «персоналок» и серверов.

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

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

В Европе, и в частности во Франции, для специалистов с высшим образованием существует чёткое разделение на выпускников инженерных школ и университетов. Первые готовят инженеров для производств, вторые – исследователей для научной и опытно-конструкторской работы. Также негласно считается, что в инженерных школах занимаются серьёзной и целенаправленной подготовкой кадров, тогда как в университетах с их большей внутренней свободой «покуривают травку» между лекциями. Чтобы не объяснять всякий раз новые российские особенности, в результате которых моя альма-матер [8] превратилась из инженерного вуза сначала в академию, а чуть позже и в университет, приходилось в резюме писать прямым текстом «инженерная школа аэрокосмического приборостроения» с устными оговорками о переименовании.

О красоте

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

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

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

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

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

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

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

6 миллионов на раздел пирога

В повести Аркадия и Бориса Стругацких «Гадкие лебеди» есть примечательный фрагмент диалога между писателем Виктором Баневым и школьниками, пригласившими его на встречу:

...

– Разрешите мне, – сказал Бол-Кунац. – Давайте рассмотрим схему. Автоматизация развивается в тех же темпах, что и сейчас. Только через несколько десятков лет подавляющее большинство активного населения земли выбрасывается из производственных процессов и из сферы обслуживания за ненадобностью. Будет очень хорошо: все сыты, топтать друг друга не к чему, никто друг другу не мешает. . И никто никому не нужен. Есть, конечно, несколько сотен тысяч человек, обеспечивающих бесперебойную работу старых машин и создание новых, но остальные миллиарды друг другу просто не нужны. Это хорошо?

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

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

В Германии совершенно серьёзно и открыто обсуждается идея выплаты всем гражданам безусловного основного дохода [9] (БОД) – минимального пособия примерно в 1000 евро, которого хватит на оплату недорого жилья, скромного питания и одежды. Пособие бессрочное и выплачивается всем гражданам независимо от того, есть у них работа или нет. Те же, кто работает, должны получать заработную плату в качестве добавки к БОД. Во Франции похожее пособие ( Revenu de SolidaritéActive ) существует достаточно давно, с 1988 года, но касается только уже потерявших право на выплаты по безработице; при этом размер пособия порядка 400 евро недостаточен для аренды жилья.

Как определить, любите ли вы свою работу, профессию, дело, которым заняты? Представим на минутку, что вы живёте в Германии и получаете свой БОД. То есть каждому дают по минимальным потребностям, а по способностям – не спрашивают. Ответьте себе честно. Имея возможность потреблять, не отдавая взамен свой труд, останетесь ли вы профессионалом в своей сфере?

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

Подобная конкуренция среди программистов имеет некоторые отличия, о которых мы и поговорим.

Круговорот

Софтостроение представляет собой соединение относительно небольшого сегмента продуктового производства массово тиражируемых системных сред, средств разработки, прикладных систем, пакетов и огромного рынка услуг, связанных с этими продуктами. Я бы оценил их соотношение как 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 ) в меню основного приложения требуется тем или иным образом её декларировать в семи-восьми разных местах, эксперт-аудитор с «чувством службы» вместо нецензурной лексики пишет «несомненно, эта ситуация стала следствием сложных обстоятельств развития системы и не является прямой ошибкой проектировщиков».

Малозначимым в глазах руководства может оказаться не только проект, но и обслуживание крупного продукта. Весьма показательный уровень программирования в одной социальной сети можно было оценить по пришедшему от их имени письму следующего содержания: « Ваши фотографии были перенесены на наш новый фотохостинг. Всего было перенесено 0 фотографий ». Для того чтобы вставить в код программы рассылки проверку IF > 0, нужно, видимо, иметь не только недюжинные умственные способности, но и дополнительную квалификацию, равно как и понимание сути выполняемой задачи. С другой стороны, да и чёрт с ними, с сотнями тысяч отправленных бесполезных писем. Одной массовой рассылкой больше, одной меньше, не правда ли?

В постиндустриальной экономике сфера услуг занимает более 50 % деятельности, и эта доля растёт, например, в США она уже близка к 70 %. Представьте себе ваш бывший школьный класс, где к работе в обслуживании ориентированы не более 25 %. Откуда же брать недостающих, да при этом еще и услужливых? Проблема, удовлетворительных решений которой на сегодняшний день не найдено. Поэтому и обсуждают введение пособий типа БОД: пусть лучше получают свой минимум и занимаются чем хотят, чем портят отношения с клиентами, мешая производительному труду остальных.