Очерки информационной технологии.
Г.Р.Громов.
Москва, ИнфоАрт, 1992, 1993.

Производительность труда программистов: факты и легенды

Темпы роста производительности труда программистов обычно приводятся в таблицах, отражающих развитие индустрии ЭВМ последней строкой - "для контраста". Как правило, все остальные данные такой таблицы приводятся лишь для того, чтобы подчеркнуть, например, как это делается в табл.2.1 и 2.2, цифры последней строки, которые отражают, по мысли их авторов, недопустимо медленный рост производительности труда программистов. В качестве единицы измерения производительности труда при этом обычно используется число строк программы, созданных за день, месяц и т.д.

Таблица 2.1

Показатели развития индустрии ЭВМ (за единицу приняты показатели 1955 г.)

По данным "01 lnformatique-Hebdo". - 1980. - Vol. 14, № IV. - P. 10 (приводится по "США - экономика, политика, идеология". - 1983. - № 8. - С. 106).

Таблица 2.2

Тенденция роста промышленности средств обработки данных (за единицу приняты показатели 1955 г.)

По данным: "Art Benjamin Associates Ltd", (приводится по:  "Электроника". - 1980. - № 11. С. 53).

Например, в обзоре "Технологические сдвиги в индустрии ЭВМ: акцент на программное обеспечение", опубликованном в журнале "Электроника", табл. 2.2 сопровождалась следующим комментарием вице-президента фирмы Primy по программному обеспечению А. Эдмонса: "Соотношение цены и характеристик аппаратуры улучшалось большими скачками, но увеличение производительности труда программистов почти равно нулю" [26, с.52].

В обзоре "Средства математического обеспечения ЭВМ: проблемы развития" авторы приводят аналогичную таблицу (см. табл. 2.1) и разъясняют: "Как видно из таблицы, рост производительности труда программистов существенно отстает от показателей развития производства и повышения технического уровня ЭВМ" [27, с.106].

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

Из приведенных оценок видно, что рост производительности труда программистов в течение длительного времени устойчиво составляет не менее чем 100% за 10 лет. В первых главах книги мы уже приводили данные, согласно которым наиболее высокие за последние десятилетия темпы роста производительности труда, достигаемые только в самых автоматизированных секторах обрабатывающей промышленности, составляют около 80% за 10 лет. Средние же темпы роста производительности труда, например в обрабатывающей промышленности США, не превышали 30% за 10 лет. Таким образом, на основании данных табл. 2.1 и 2.2, которые приводились их авторами, чтобы подчеркнуть медленные темпы роста производительности труда программистов, может быть сделан прямо противоположный вывод о рекордных, невиданно высоких темпах роста их производительности.

Какой из двух противоположных по смыслу выводов, сделанных по одним и тем же статистическим данным, является верным?

Если ошибочность первого вывода (о медленных темпах роста производительности программистов) заключается в сопоставлении характеристик людей и машин, то ошибочность второго (о рекордных темпах роста этого показателя) - в "реликтовом" способе измерения производительности труда программистов.

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

Спустя 30 лет так много изменилось в программировании, что сопоставлять производительность труда программистов 50-х и 80-х годов оказалось нельзя: принципиально иным стал характер труда и соответствующие единицы его измерения. Если в 50-х годах решались в основном хорошо определенные задачи и соответственно главной производственной проблемой программистов было корректно перевести точные формальные спецификации в эффективный код программы, то в 80-х годах большая часть профессиональных программистов - это системные аналитики, которые, потребляя свыше 70% общих ресурсов, выделяемых на программирование, вообще не создают ни одной строки программного кода, а заняты лишь анализом приложений и постановкой задачи. Как в этих условиях можно оценивать темпы роста производительности труда программистов по скорости, с которой они создают программный код?

Из приводимых на рис. 2.8 данных о структуре распределения трудозатрат на программирование видно, что даже если бы завтра оказалось возможным создать, наконец, долгожданный "перпетуум мобиле" большой науки программирования - автоматический синтезатор любых программ (т.е. повысить производительность труда программистов, измеряемую в строках кода в день, от существующего уровня в 100% за 10 лет до "бесконечности" или предела, определяемого темпом загрузки в этот "автомат" спецификаций на программы), то это почти не снизило бы трудоемкость выполняемых проектов (уменьшение трудоемкости составило бы 15-20% для традиционных областей приложений и 3 - 5% для наиболее массовых в настоящее время областей приложений ЭВМ).

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

Рис. 2.8. Динамика структуры трудозатрат по фазам проекта в 1970 -1980 гг.

1  - сопровождение и поддержка;

2  - анализ приложений и постановка задачи;

3  - кодирование и автономная отладка;

4  - комплексная отладка и приемосдаточные испытания.

Рассчитано по "01 lnformatique-Hebdo". - 1980. - Vol. 14. № IV. - P.35; данным фирмы TRW (приводится в: "Зарубежная радиоэлектроника". - 1974. - № 12. - С. 9)

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

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

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

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

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

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

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

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

"Они рассматривают процесс передачи контроля над вычислительными ресурсами конечному пользователю как прямую угрозу основам их власти; реальную угрозу уменьшения их бюджета, а потенциально и утрату контроля над формированием технической политики. Эти руководители достигли высокого социального положения, больших окладов и других привилегий, овладев в совершенстве старыми методами. Если принципиально новые методы работы с ЭВМ будут внедрены, они окажутся перед необходимостью переучиваться, т.е. начать все с начала. Почему же тогда нас удивляет, что они так активно сопротивляются? Причем необходимо отмстить, что это весьма могущественное сопротивление, так как именно они контролируют доступ в кабинеты, где принимаются ключевые решения, а также другие сферы власти" [28, с.209].

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

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

Онлайн-версия CD-ROM приложения к книге Г.Р.Громова
"От гиперкниги к гипермозгу: информационные технологии
эпохи Интернета. Эссе, диалоги, очерки."