Об измерении труда программистов

(сообщение на семинаре по Р-технологии, 28.02.86, пос. Славско)

Сначала о названии. Сообщение называется "Об измерении", а не "Измерение". Это означает, что конкретная метрика не будет предложена, а значит, то, что я буду говорить, не является вступлением к изложению метрики. По моему глубочайшему убеждению, время метрик для данной проблемы ещё не настало. Сейчас время ставить вопросы, а не отвечать на них. Вот вопросам-то и посвящено моё сообщение. Я хотел назвать его ещё и так: "заметки дилетанта", поскольку единственное, что я умею более-менее делать - это программировать, а занявшись этой проблемой, я вынужден был влезть и в психологию, и в философию, и в экономику, и даже в нейрофизиологию. Понятно, что в этих науках я дилетант, но и это ещё не всё. По образованию я математик, и естественно, что понятия, очевидные для любого инженера, для меня довольно чужды. К чему я это говорю? А вот к чему - если среди вас есть люди, лучше меня разбирающиеся в указанных науках, то я им буду очень благодарен, ели ни в соответствующий момент укажут на то, что я говорю глупости. Но пускай они тогда ещё и ответят на те вопросы, которые меня, по моему невежеству, очень мучают.

Теперь ещё одно лирическое отступление - я хочу пояснить, как я вышел на эту проблему и почему она меня так трогает. Поясняю - у меня с ней личные счёты. Когда-то я, без особых претензий на что-либо, скромно решил исследовать собственную производительность труда. Данные у меня были - по всем программам, которые я писал, я замерял затраченное время с точностью до минут. Тексты этих программ у меня тоже были - я их никогда не выбрасываю. И вот я, недолго думая, ввёл в базу данных данные о затратах времени, все 50000 штук, и перелопатил свои распечатки, подсчитывая длины программ по самой передовой из всех методик - методике Холстеда. У меня даже мысли не возникло сомневаться в этом способе измерения - я полагался на авторитет Холстеда, Липаева, Брукса и прочих. Что из этого получилось, большинство, наверное, знает: оказалось, что длина программы имеет весьма слабое отношение к объёму работы, а значит, весь мой труд был напрасен. Кто-то может возразить: это данные по одному человеку. Отвечаю: после этого я обработал и другие данные. У нас в Красноярске проводятся конкурсы программистов. Собираются 20-40 лучших программистов города и решают одну задачу. Задача одна, время одинаковое (один человеко-день, т.к. конкурс проходит за один день), а вот длины программ существенно разные. Вот цифры: разбросы длин от 17 до 129 операторов, доверительный интервал длин от 30 до 90 операторов, т.е. в пределах доверительного интервала длина "плавает" в три раза. Чему же тут можно доверять?

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

За примерами далеко ходить не надо. Известный способ измерения производительности труда программистов в операторах или байтах есть простое следствие двух расхожих фраз: "Программист изготавливает программную продукцию. Производительность труда есть количество продукции, произведённой в единицу времени". Эти фразы вызывают у нас идиллическую картину: вот программист, который что-то клепает и привинчивает, в результате чего появляется программная продукция. Этой продукции может быть много или мало, и на её производство может быть потрачено много или мало времени, дальше всё покатилось как по маслу. Поскольку программист работает с текстом программы, программа и есть программная продукция. Если она большая, значит, продукции много. А если маленькая - значит, мало. Теперь осталось поделить длину на время, и готово дело. Этот критерий можно совершенствовать до бесконечности - увеличивать точность измерения времени от лет до минут, объём продукции измерять сначала в килограммах колод, потом в строках текста, потом в операторах, потом по Холстеду или ещё как-нибудь, но по сути ничто не меняется, и по этой дороге можно идти очень долго, а значит, можно уйти от истины очень далеко.

Пока не поздно, нужно остановиться и задать себе ряд вопросов. Я правда, позволю себе ещё одно лирическое отступление. Как нас учили математике? Меня учили так: я говорю: "Возьмём инфинум множества", а мне говорят: "А у всякого ли множества есть инфинум?". И я доказываю, что да, у всякого, и потому есть и у того, с которым я имею дело. И я снова бодро говорю "возьмём инфинум множества", на что мне говорят: "Который? Может быть, их несколько?!". И я доказываю, что нет, только один. И снова я бодро говорю: "Возьмём инфинум множества", а мне говорят "А вы уверены, что если он есть, вы сумеете его взять?". И так далее.

И я вспомнил, что всё же я математик и задал себе ряд вопросов, на первый взгляд абсолютно дурацких: "А изготавливает ли что-либо программист? А является ли то, что он изготавливает, программной продукцией? Если нет, то кем изготавливается программная продукция? Что вкладывал в понятие количества тот человек, который дал определение производительности труда? Действительно ли производительность труда измеряется количеством продукции? Действительно ли следует делить на время и есть ли разница между единицами времени?"

Я над этими вопросами подумал и сейчас хотел бы поделиться с вами своими рассуждениями.

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

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

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

К вопросу о том, что вкладывается в понятие "количество продукции". Мы интуитивно ищем некий натуральный показатель - килограммы, тонны, операторы, дуги и т.д. Экономисты же вкладывают в это понятие совсем другой смысл. Они имеют в виду стоимость произведённой продукции.

Точнее говоря, они применяют и натуральные показатели, но считают, что имеет смысл только в добывающей промышленности, где продукция совершенно однородна. Кстати, когда я консультировался с экономистами, они сказали вполне серьёзно: "Да ведь у вас всё нормально - полностью однородная продукция - операторы". На что я, тоже серьёзно, ответил, что, если бы производили именно операторы, то мы бы ими страну просто завалили. Но мы производим что-то другое, и оценивать нужно именно это.

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

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

Где есть три способа, можно поискать и четвёртый, не так ли?

Переходим к следующему вопросу. Изготавливает ли что-то программист? По этому поводу наблюдается полный разброд мнений. С одной стороны программным изделием вроде бы считается загрузочный модуль, поскольку именно к нему относится фаза копирования и распространения. С другой стороны, существует мнение, что программным изделием является функционирующая программа. И в том, и в другом случае, непонятно, какое отношение имеет к программному изделию исходный текст программы. К тому же, если копирование (изготовление) изделия происходит в момент перезаписи ленты, то имеем ли мы право называть написание программы изготовлением изделия? Гантер говорит по этому поводу так: программисты изготавливают опытный образец изделия, который потом тиражируется. Где в таком случае заканчивается проектирование изделия и где начинается его изготовление? Существует даже (кажется, в СКС-технологии) термин "программостроительное предприятие".

Все эти рассуждения вертятся по замкнутому кругу. Этот круг порождён вроде бы очевидным утверждением, что программист является тем лицом, которое, участвуя в программном производстве, производит программную продукцию. Это не так тривиально. Не всякая деятельность в сфере производства является изготовлением. Водитель автокара участвует в производстве, но сам лично ничего не производит. Пример ближе к нашему: производит что-либо технолог, разрабатывающий программы для станков с ЧПУ? Он производит болты, которые вылетают из этого станка, или кто-то другой? Скорее, всё-таки, не он. И он, кстати, достаточно скромен, чтобы называть изделием болт, а не программу его изготовления, и он называет себя технологом, а программу - технологией. И с нормированием их труда поэтому всё обстоит нормально - их труд нормируется именно как труд технолога. В частности, им не приходит в голову подсчитывать строки текста: они установили категории сложности технологии в зависимости от сложности изделия (например, в соответствии с количеством размерностей), и всё.

Видите ли вы какую-нибудь разницу между трудом этих технологов и нашим? Я лично не вижу. ЭВМ - это станок с ЧПУ, и именно он производит программные изделия, а программа - не более чем технология их изготовления.

Да, но что же тогда является программным изделием? Какие программные изделия изготавливает программа, вычисляющая, например, факториалы? Ответ предельно прост: программа эта производит ничто иное, как факториалы. Факториалы и есть программные изделия. Не надо, впрочем, путать число, напечатанное на АЦПУ, с изделием "факториал". Число - это результат нашего взаимодействия и изделием, это уже продукция самого программного изделия. Само же изделие - это материализовавшееся понятие факториала. Мы знаем, что абстрактное понятие факториала имеет определённые свойства. Например, что это понятие не определено для отрицательных чисел, что факториал пяти - это сто двадцать, и т.д. И, исследуя машину с выполняющейся на ней программой вычисления факториала, как чёрный ящик, мы убеждаемся, что имеется физический объект, имеющий все свойства абстрактного понятия "факториал". Заметим, что и болт точно так же является материализацией абстрактного понятия "болт" на определённом носителе. И исследуя его, мы убеждаемся, что это действительно болт, поскольку на него можно накрутить гайку, у него определённой формы шляпка и т.д.

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

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

1. Конструкторская, когда выделяются изготавливаемые понятия и определяются связи между ними (в случае факториала это понятие числа и произведения чисел. Так же, как в случае двигателя, передачи и колёса мы можем говорить о трёх исходных изделиях, так и для факториала).

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

3. Производственная, когда изделия (понятия) непосредственно изготавливаются. Очевидно, что это происходит в тех ВЦ, где программы (технологии) запускаются.

Только в последнем случае мы можем говорить о производительности труда в обычном понимании, т.к. только там выпускается массовая продукция. Грубо говоря, ВЦ должно производить столько факториалов, чтобы их хватило всем нуждающимся, а это зависит от того, быстра или медленна технология производства факториалов, качественна она или некачественна, ресурсоёмка или нет; но она остаётся именно технологией, не претендуя на то, чтобы называться изделием.

Что касается конструкторского и технологического этапов, то тут явно нужно замерять не количество продукции, выпускаемой в единицу времени, а время, затрачиваемое на этап, с учётом категории сложности. Я подчёркиваю, что эта сложность не должна рассчитываться по сложности программы (для любой произвольно простой задачи можно написать произвольно сложную программу). Категория сложности должна рассчитываться исходя из двух положений. Во-первых, должна быть измерена сложность понятий, созданных на этапе конструирования. Программист-технолог должен разработать технологию изготовления именно этого изделия, а не какого-то другого. Может быть, можно сделать изделие с такими же функциями, устроенное проще, но это дело конструктора, а не технолога. Итак, сверху ему задан уровень сложности изделия, т.е. сложность понятий и сложность их взаимосвязей.

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


© Алексей Бабий 1986