Экономический сдвиг погрешностей

alexthunder — 09.08.2012 Интересное на мой взгляд явление происходит с экономикой когда ею занимаются исключительно экономисты. Особенно интересно когда это экономика научной или иной изыскательской деятельности.

Экономист он ведь что делает? Верно - сокращает издержки. Устраняет те участки деятельности которые чего-то стоят, но мало чего приносят.

Возьмём теперь для примера такое занятие как скажем изготовление программного обеспечения. Ну или другой пример - изготовление космических спутников.

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

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

А вот и нет!

Дело в том что почти любая новая программа как и любой "запуск" - это всегда работа с неизвестным. Много есть книжек о "программировании вообще" и нет ни одной о том как правильно сделать вот именно эту программу. Много есть учебников по механике и коснтруированию, но нет ни единой книжки о том как сделать правильно вот именно этот спутник. А значит что каждая работа предполагает работу с чем-то неизвестным, доселе невиданным. В чём суть это работы?

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

Сделали программу которая складывает числа, проверили, работает. Выдали в эксплуатацию - не работает. Как так? Спрашиваем - как проверяли.
Отвечают - на вот этом примере. Взяли один пример - для этого примера работает.
- Отлично. А для вот этого работает?
- Нет, для этого не проверяли.
- Тоесть для 1 сделали, а для 2 не пробовали.
- Нет, но сейчас быстренько исправим будет работать для 2. Сделали вот. Проверяйте.
- Проверяем. Для 1 работает, для 2 работает. Для 3 - не работает.
- А... А зачем вам 3?
- Ну как зачем. Надо чтобы работало и для 1 и для 2 и для 3.
- Хорошо. Сейчас быстренько исправим. Вот исправили уже. Работает для 3 - проверяйте.
- Проверили - работает для 1, работает для 2, работает для 3. Для 4 - не работает.
- Четыыыыре?! Про четыре вы ничего не говорили, в задании не написано что для 4 должно работать.

И вот так дальше. Тупые разработчики?

Нет. Тупое руководство. По моей теореме руководитель всегда получает именно то что заказывал. Если он "сэкономил" на формулировке задания - получил "что-то вроде вот как-то так" вместо того что на самом деле надо. Для 1 работает, для 2 работает, для 3 - не заказывали.

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

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

Тем самым все риски аккумулируются к моменту собственно запуска.

Если это запуск программного обеспечения, то возникает эффект отладки "на клиенте". Это когда всё что должно быть выявлено ДО сдачи становится видно пользователю. "Справедливый" гнев начальства в данном случае исходит из того что мол потрачено же время на разработку "вон аж сколько". А то что любое обнаружение после старта - это недотестированное, недоисправленное, недоделанное что-то на что следовало бы ПОТРАТИТЬ время раньше - это в голову не приходит. Не догадываются экономисты что затраты эти неизбежны и что тратить будешь всё равно - вопрос лишь в том когда, вначале до запуска или потом - после запуска. Но тратить-то будешь точно, не сэкономишь на этом ну никак.

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

Потому что одной копейки недовложенной в один единственный мелкий этап разработки будет достаточно чтобы вся работа целиком пошла на смарку.

Вот такая экономия в Research & Development.

Оставить комментарий

Популярные посты:

• Архив