Экономический сдвиг погрешностей
Aug. 10th, 2012 07:51 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
alexthunderИнтересное на мой взгляд явление происходит с экономикой когда ею занимаются исключительно экономисты. Особенно интересно когда это экономика научной или иной изыскательской деятельности.
Экономист он ведь что делает? Верно - сокращает издержки. Устраняет те участки деятельности которые чего-то стоят, но мало чего приносят.
Возьмём теперь для примера такое занятие как скажем изготовление программного обеспечения. Ну или другой пример - изготовление космических спутников.
Что общего между тем и другим. А общее - это сотрудничество экономистов и исследователей, инженеров. И в этом соутрдничестве есть один очень интересный конфликт. Конфликт между необходимостью что-то сделать и необходимостью сокращать по возможности издержки.
Для экономиста всё выглядит весьма просто - всё должно быть хорошенько и очень точно и очень правильно "расчитано", очень аккуратно без разгильдяйства изготовлено и также аккуратно и прилежно введено в эксплуатацию. Всё. Дальше получается результат - порграмма работает "как часы", а спутник занимает своё место на орбите. Если результат получился какой-то иной, то это значит что? По мнению экономиста - это разгильдяйство допущеное инженерами исследователями. Допустили просчёты, не сделали "как надо". Звучит справедливо правда?
А вот и нет!
Дело в том что почти любая новая программа как и любой "запуск" - это всегда работа с неизвестным. Много есть книжек о "программировании вообще" и нет ни одной о том как правильно сделать вот именно эту программу. Много есть учебников по механике и коснтруированию, но нет ни единой книжки о том как сделать правильно вот именно этот спутник. А значит что каждая работа предполагает работу с чем-то неизвестным, доселе невиданным. В чём суть это работы?
Суть в том что изыскатель вынужден предпринять серию попыток добиться того или иного промежуточного результата на пути к общему конечному. Каждый промежуточный результат - это всегда вопрос и всегда вопрос спорный. Всегда есть некие исходные предпосылки исходя из которых делает тот или иной узел. И всегда есть тесты позволяющие оценить этот промежуточный результат, сравнить с ожидаемым. И вот тут стоит привести пример "китайского" программирования. Я с этим постоянно сталкиваюсь на работе, называю это "китайским" программированием в честь создателей этого подхода к делу.
Сделали программу которая складывает числа, проверили, работает. Выдали в эксплуатацию - не работает. Как так? Спрашиваем - как проверяли.
Отвечают - на вот этом примере. Взяли один пример - для этого примера работает.
- Отлично. А для вот этого работает?
- Нет, для этого не проверяли.
- Тоесть для 1 сделали, а для 2 не пробовали.
- Нет, но сейчас быстренько исправим будет работать для 2. Сделали вот. Проверяйте.
- Проверяем. Для 1 работает, для 2 работает. Для 3 - не работает.
- А... А зачем вам 3?
- Ну как зачем. Надо чтобы работало и для 1 и для 2 и для 3.
- Хорошо. Сейчас быстренько исправим. Вот исправили уже. Работает для 3 - проверяйте.
- Проверили - работает для 1, работает для 2, работает для 3. Для 4 - не работает.
- Четыыыыре?! Про четыре вы ничего не говорили, в задании не написано что для 4 должно работать.
И вот так дальше. Тупые разработчики?
Нет. Тупое руководство. По моей теореме руководитель всегда получает именно то что заказывал. Если он "сэкономил" на формулировке задания - получил "что-то вроде вот как-то так" вместо того что на самом деле надо. Для 1 работает, для 2 работает, для 3 - не заказывали.
Тоже самое и с собственно затратами на изыскания и тесты. Экономисту кажется что всё должно с первой попытки работать. Ему, экономисту, кажется что разработчик каким-то чудом должен с первого раза взять и сделать всё правильно. А то что в процесс этого деланья входят многочисленные попытки "сделал, проверид, не работает, сделал иначе" - это сокрытая от экономиста тайна. Ему кажается что одной попытки достаточно всегда, надо просто "правильно" делать и всё. А как именно "правильно" - это не его экономиста проблема, это должны знать исследователи.
В результате экономисески-подкованное начальство переносит все обнаружения ошибок на самый конец. Исключает из затрат все возможности что-либо протестировать для достаточного количества исходных вариантов. Исключает возможность переделать сколько надо раз то что вызывает сомнения. Исключает возможность потратить время во время разработки.
Тем самым все риски аккумулируются к моменту собственно запуска.
Если это запуск программного обеспечения, то возникает эффект отладки "на клиенте". Это когда всё что должно быть выявлено ДО сдачи становится видно пользователю. "Справедливый" гнев начальства в данном случае исходит из того что мол потрачено же время на разработку "вон аж сколько". А то что любое обнаружение после старта - это недотестированное, недоисправленное, недоделанное что-то на что следовало бы ПОТРАТИТЬ время раньше - это в голову не приходит. Не догадываются экономисты что затраты эти неизбежны и что тратить будешь всё равно - вопрос лишь в том когда, вначале до запуска или потом - после запуска. Но тратить-то будешь точно, не сэкономишь на этом ну никак.
Если же речь о запуске оборудования на орбиту, то всё ровно точно также. С одной разницей - программу можно пытаться исправлять при заказчике. Краснея, потея, недосыпая, но можно. А вот спутник - нельзя. Недозатраченное в процессе разработки программы - будет дозатрачено потом. А вот недозатраченное при изготовлении спутника - аннулирует полностью все сделанные затраты целиком. Вот в этом и разница. Программы с хронической "экономией" делать ещё как-то можно, а спутники увы нет. Там или ты вкладываешь сколько требуется на всех этапах работы или лучше не затевать этого вовсе.
Потому что одной копейки недовложенной в один единственный мелкий этап разработки будет достаточно чтобы вся работа целиком пошла на смарку.
Вот такая экономия в Research & Development.
Экономист он ведь что делает? Верно - сокращает издержки. Устраняет те участки деятельности которые чего-то стоят, но мало чего приносят.
Возьмём теперь для примера такое занятие как скажем изготовление программного обеспечения. Ну или другой пример - изготовление космических спутников.
Что общего между тем и другим. А общее - это сотрудничество экономистов и исследователей, инженеров. И в этом соутрдничестве есть один очень интересный конфликт. Конфликт между необходимостью что-то сделать и необходимостью сокращать по возможности издержки.
Для экономиста всё выглядит весьма просто - всё должно быть хорошенько и очень точно и очень правильно "расчитано", очень аккуратно без разгильдяйства изготовлено и также аккуратно и прилежно введено в эксплуатацию. Всё. Дальше получается результат - порграмма работает "как часы", а спутник занимает своё место на орбите. Если результат получился какой-то иной, то это значит что? По мнению экономиста - это разгильдяйство допущеное инженерами исследователями. Допустили просчёты, не сделали "как надо". Звучит справедливо правда?
А вот и нет!
Дело в том что почти любая новая программа как и любой "запуск" - это всегда работа с неизвестным. Много есть книжек о "программировании вообще" и нет ни одной о том как правильно сделать вот именно эту программу. Много есть учебников по механике и коснтруированию, но нет ни единой книжки о том как сделать правильно вот именно этот спутник. А значит что каждая работа предполагает работу с чем-то неизвестным, доселе невиданным. В чём суть это работы?
Суть в том что изыскатель вынужден предпринять серию попыток добиться того или иного промежуточного результата на пути к общему конечному. Каждый промежуточный результат - это всегда вопрос и всегда вопрос спорный. Всегда есть некие исходные предпосылки исходя из которых делает тот или иной узел. И всегда есть тесты позволяющие оценить этот промежуточный результат, сравнить с ожидаемым. И вот тут стоит привести пример "китайского" программирования. Я с этим постоянно сталкиваюсь на работе, называю это "китайским" программированием в честь создателей этого подхода к делу.
Сделали программу которая складывает числа, проверили, работает. Выдали в эксплуатацию - не работает. Как так? Спрашиваем - как проверяли.
Отвечают - на вот этом примере. Взяли один пример - для этого примера работает.
- Отлично. А для вот этого работает?
- Нет, для этого не проверяли.
- Тоесть для 1 сделали, а для 2 не пробовали.
- Нет, но сейчас быстренько исправим будет работать для 2. Сделали вот. Проверяйте.
- Проверяем. Для 1 работает, для 2 работает. Для 3 - не работает.
- А... А зачем вам 3?
- Ну как зачем. Надо чтобы работало и для 1 и для 2 и для 3.
- Хорошо. Сейчас быстренько исправим. Вот исправили уже. Работает для 3 - проверяйте.
- Проверили - работает для 1, работает для 2, работает для 3. Для 4 - не работает.
- Четыыыыре?! Про четыре вы ничего не говорили, в задании не написано что для 4 должно работать.
И вот так дальше. Тупые разработчики?
Нет. Тупое руководство. По моей теореме руководитель всегда получает именно то что заказывал. Если он "сэкономил" на формулировке задания - получил "что-то вроде вот как-то так" вместо того что на самом деле надо. Для 1 работает, для 2 работает, для 3 - не заказывали.
Тоже самое и с собственно затратами на изыскания и тесты. Экономисту кажется что всё должно с первой попытки работать. Ему, экономисту, кажется что разработчик каким-то чудом должен с первого раза взять и сделать всё правильно. А то что в процесс этого деланья входят многочисленные попытки "сделал, проверид, не работает, сделал иначе" - это сокрытая от экономиста тайна. Ему кажается что одной попытки достаточно всегда, надо просто "правильно" делать и всё. А как именно "правильно" - это не его экономиста проблема, это должны знать исследователи.
В результате экономисески-подкованное начальство переносит все обнаружения ошибок на самый конец. Исключает из затрат все возможности что-либо протестировать для достаточного количества исходных вариантов. Исключает возможность переделать сколько надо раз то что вызывает сомнения. Исключает возможность потратить время во время разработки.
Тем самым все риски аккумулируются к моменту собственно запуска.
Если это запуск программного обеспечения, то возникает эффект отладки "на клиенте". Это когда всё что должно быть выявлено ДО сдачи становится видно пользователю. "Справедливый" гнев начальства в данном случае исходит из того что мол потрачено же время на разработку "вон аж сколько". А то что любое обнаружение после старта - это недотестированное, недоисправленное, недоделанное что-то на что следовало бы ПОТРАТИТЬ время раньше - это в голову не приходит. Не догадываются экономисты что затраты эти неизбежны и что тратить будешь всё равно - вопрос лишь в том когда, вначале до запуска или потом - после запуска. Но тратить-то будешь точно, не сэкономишь на этом ну никак.
Если же речь о запуске оборудования на орбиту, то всё ровно точно также. С одной разницей - программу можно пытаться исправлять при заказчике. Краснея, потея, недосыпая, но можно. А вот спутник - нельзя. Недозатраченное в процессе разработки программы - будет дозатрачено потом. А вот недозатраченное при изготовлении спутника - аннулирует полностью все сделанные затраты целиком. Вот в этом и разница. Программы с хронической "экономией" делать ещё как-то можно, а спутники увы нет. Там или ты вкладываешь сколько требуется на всех этапах работы или лучше не затевать этого вовсе.
Потому что одной копейки недовложенной в один единственный мелкий этап разработки будет достаточно чтобы вся работа целиком пошла на смарку.
Вот такая экономия в Research & Development.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-08-10 04:02 am (UTC)Это вот начало твоей реплики такое было если может быть ты позабыл. Словосочетание "данные типы" указывает в нём на некое предварительное указание того какие именно "данные" и "типы".
А реплика эта была в ответ на ту в которой слово "убытки" не употреблялось, а только затраты.
Такчта эта...
no subject
Date: 2012-08-10 04:14 am (UTC)«—Я думаю, в данном контексте более уместно употребление термина "расходы"
—Пожалуй, ты прав, хотя неоптимизированные, завышенные расходы можно смело отнести к убыткам.
—Пожалуй, да. В этом смысле ты тоже прав.»
А теперь перечитай как ты витеивато и с завуалированным переходом на личность собеседника, сообщил эту же самую информацию.
no subject
Date: 2012-08-10 04:23 am (UTC)В моём-то понимании оптимизировать можно как раз затраты, а убытки оптимизировать нельзя.
Ты же вот вновь утверждаешь что якобы есть какие-то оптимизируемые затраты которые якобы можно сразу считать убытками. Тоесть якобы если можно было непотратить, то значит это убытки.
Вот именно ЭТО выдаёт в тебе... ээээ. японца теплофизического.
И вот мой поинт был именно в этом, а не в выборе слов.
Понимаешь, Аркаша, это вот тебе кажется что якобы затраты которые можно было не потратить - есть убытки. Тебе и ещё ряду людей.
Так вот у некоторых людей спутники летают, а у некоторых таки падают или летают не туда. Отличает одних от дургих как раз вот эта самая привычка думать что если можно не потратить - значит это убытки. Именно эта точка зрения приводит к падениям.
Ферштейн?
no subject
Date: 2012-08-10 04:27 am (UTC)