Процесс программного обеспечения

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

Рассматривая элементарный акт компьютеризации, мы с неизбежностью находим 1) некоторую деятельность, 2) представление (верное или ошибочное) о том, что ее можно осуществлять с помощью компьютера более эффективно (или, например, приятно), и, как следствие, 3) более или менее оформленную и артикулированную потребность в программе ¹, позволяющей реализовать 4) соответствующее приложение (рис. 1).

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

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

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

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

И несомненно, что программирование оказалось частично захвачено этой моделью (рис. 2), и все перечисленные явления имеют место быть. Однако если мы посмотрим на массовые приложения компьютеров и зададимся вопросом: а кто их реально программирует? - мы увидим, что:

• значительная часть программирования выполняется самими пользователями (если понимать программирование буквально - как прописывание наперед тех операций и процедур, которые должен осуществить компьютер, в противоположность непосредственному манипулированию данными более или менее в режиме реального времени - и, соответственно, включить сюда выполняемую пользователями настройку программ, автоматизацию рутинных действий и т. п.);

• сопоставимая (и, вероятно, большая) доля выполняется программистами и администраторами, нанятыми лицом (организацией), осуществляющим приложение. Доля профессиональной программистской рабочей силы, непосредственно потребляемой таким способом, огромна и достигает, по некоторым оценкам, 95%;

• доля, выполняемая нанятыми под определенный заказ программистами, командами или компаниями, по меньшей мере, заметна;

• совсем небольшая часть профессии занята разработкой отчуждаемых и вводимых в широкий оборот «продуктов».

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

Сам по себе этот факт совсем не уникален. «Сопротивление» индустриализации оказывают все сервисные по своей сути профессии и сферы деятельности.

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

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

Специфика сферы услуг подсказывает, что, возможно, вместо применения кооперативной модели стоит рассмотреть программное обеспечение как особого рода коммуникацию (рис. 3). Это предполагает, разумеется, не просто смену картинки, а совсем другую категорию, организующую мысль. Эффективность коммуникации зависит совсем от других условий, нежели эффективность кооперации ².

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

Далее, важна также свобода позиционирования участников коммуникации; можно ожидать, что при минимизации издержек на позиционирование мы вместо жесткого противопоставления «программистов» «пользователям» получим континуум, градиент программного обеспечения между «полюсами тяготения»: «разработкой» (где затраты выше выгоды от использования) и «использованием» (где выгода использования превышает затраты).

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

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

Хотя опыт показывает, что нельзя игнорировать «автомотивацию» программистов по внеэкономическим соображениям (профессиональную, академическую, престижную, которая косвенно может также быть экономической), понятно, что, какую бы форму ни приняло движение этих ресурсов, в конце концов, пользователи в совокупности:

• оплатят затраты на программирование и

• при прочих равных получат столько, за сколько они заплатили.

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

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

• непосредственный наём программистов пользователем либо контрактация с профсервисной компанией ⁴;

• привлечение посредника («софтверной компании») ⁵;

• наём программистов производителем или поставщиком «железа» ⁶;

• наём программистов поставщиком профессиональных услуг;

• оплата программирования третьей стороной: общественной организацией (за счет ее членов/доноров) или государством (за счет налогоплательщика) ⁷.

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

1. Поскольку программы представляют собой не физические объекты (счетные единицы), а свободно копируемые фрагменты информации, приходится вводить такую фикцию, как исключительные права («интеллектуальная собственность»), что влечет за собой общественные расходы на ее реализацию (enforcement) и макроэкономически означает дотации, спонсирование бизнес-моделей, основанных на посредничестве на рынках «интеллектуальной собственности»: часть совокупных затрат, обычно упускаемых при анализе.

2. С одной стороны, нелепая жесткость ограничений, вводимых типичными несвободными лицензиями ⁸, а с другой стороны, недоступность исходных текстов и несвобода инструментальных средств не позволяют пользователю вносить в программы даже те изменения, которые с очевидностью проще и удобнее осуществлять с пользовательской стороны ⁹. Похоже на то, как если бы для замены лампочки в своей квартире вам пришлось бы обращаться в РАО «ЕЭС России».

3. В более широком смысле, несвободное лицензирование (и обычно сопутствующая ему практика утаивания исходных текстов) ведет к затруднению коммуникации между самими программистами, а также между ними и пользователями. Соответственно, доминирующий в определенном классе приложений «интеллектуальный собственник» оказывается в состоянии контролировать такую коммуникацию (как технически, дозируя информацию, так и организационно, связывая коммуникантов различными ограничивающими их свободу обязательствами). Успешная реализация такой стратегии может привести к тому, что общее пространство коммуникации практически распадется, и с его деградацией открытый рынок услуг по поддержке процесса программного обеспечения заместится системой «частных рынков» - цепочек сделок, полные условия которых известны только «интеллектуальному собственнику» ¹⁰.

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

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

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

[i41644]