Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Как по мне, выводы из зефирного теста неправильные делают. Те, кто берут одну сейчас вместо двух потом правы по многим причинам. Завтра могут не дать вообще. Не смогут, обманут, человек куда-то пропадет или зефир. Или будет уже не тот, хуже качество, меньше размер и т.д. Другое дело если смогут гарантии предоставить. Но почему то создатели теста много чего не предусмотрели. И с пенсионным фондом то же самое. Нельзя никому ничего доверять. Вроде как государство - гарант, а вроде как есть инфляция, изменение законодательства, изменение условий при начислении и выдачи пенсий. Все хотят, чтобы кто-то другой позаботился, кто-то более надежный, ответственный, стабильный и успешный. В итоге приходим к тому, что лучше делать все самому.
А покупать вещи для будущего себя считаю, что все таки не лишнее. К спорту и к музыке можно возвращаться не один раз. Конечно, в этом плане аренда для всех предпочтительнее. Если один раз купил, то потом не платишь, из-за этого и не ценишь.
Как говорил Аристотель: "Одни копят, словно должны жить вечно, другие тратят, словно тотчас умрут."
За тысячелетия ничего в этом плане не поменялось.
А покупать вещи для будущего себя считаю, что все таки не лишнее. К спорту и к музыке можно возвращаться не один раз. Конечно, в этом плане аренда для всех предпочтительнее. Если один раз купил, то потом не платишь, из-за этого и не ценишь.
Как говорил Аристотель: "Одни копят, словно должны жить вечно, другие тратят, словно тотчас умрут."
За тысячелетия ничего в этом плане не поменялось.
В статье действительно подмечены алгоритмы оценки нужности текущих задач и личных вещей, выражаю респект автору.
Однако должен заметить будущее не предсказуемо (на 100%), поскольку увы эффект бабочки никто не отменял . Даже система из Земли и Луны движущийся в вакууме вокруг Солнца увы не предсказуема на больших периодах. Не возможно все предусмотреть, даже если я это тот же я в будущем, по практическим причинам принятые решения очень возможно будут ошибкой, особенно в больших периодах.
Поэтому в периоде скажем 20 лет нет смысла думать о старости, но иметь денежную подушку безопасности есть. Нет смысла надеяться на удачу, особенно если не знаешь в чем она должна выразиться и каковы шансы этого события, лучше самому найти и сделать все необходимое чтоб тебе "повезло".
Однако должен заметить будущее не предсказуемо (на 100%), поскольку увы эффект бабочки никто не отменял . Даже система из Земли и Луны движущийся в вакууме вокруг Солнца увы не предсказуема на больших периодах. Не возможно все предусмотреть, даже если я это тот же я в будущем, по практическим причинам принятые решения очень возможно будут ошибкой, особенно в больших периодах.
Поэтому в периоде скажем 20 лет нет смысла думать о старости, но иметь денежную подушку безопасности есть. Нет смысла надеяться на удачу, особенно если не знаешь в чем она должна выразиться и каковы шансы этого события, лучше самому найти и сделать все необходимое чтоб тебе "повезло".
Для меня чтение и обдумывание подавляющего большинства творений Ивана сродни полному циклу поедания тортика: начало отличное, увлекательное, жизненное (тортик вкусный), середина "провисает" (тортик съеден, голод утолен), а концовка и выводы всегда вызывают недоумение (тортик переварился и на выходе мы получаем известную субстанцию).
Вот подметил все точно, в наблюдательности не откажешь, сам замечаю что большинство изменений информационных систем, особенно на базе 1С, забывается уже через несколько использований и потом не возвращаются к нему. В этом полностью согласен. А если в реале существует даже и подсистема СИФА - ссылку в студию пожалуйста, за такое не пожалею и 5 стартмани!
Но вот переход про собственника (А что за завод, на котором программист с собственником может пообщаться? Завод по производству шавермы?) уже вызвал недоумение, выводы про всякие "Я" и вовсе непонятно что и зачем. Потому что наблюдения и анализ ситуации явно эмпирические, а выводы - фантастические. Как их использовать непонятно. Ну, может я тупой просто, не догоняю...
Одна надежда, на интересные мысли в комментариях, если повезет... )))
Я вот думаю, что причиной внесения любых изменений в ИС должна быть экономическая целесообразность: если полученный эффект превышает затраты на разработку - делаем. Даже если это будет одноразовая обработка или отчет.
Тут многим внутренним заказчикам надо уяснить, что программист не бесплатный. Даже если это программист штатный и на фиксированном окладе. И пока он делает им очередную хотелку, выхлоп от которой три копейки, а затраты на рубль - он в этот момент НЕ ведет разработку вещей у которых затраты на рубль, а выхлоп на тысячу. Причем бремя оценки экономической целесообразности должно ложиться на руководителей отделов Заказчика и Разработки, они совместно должны оценивать и составлять список доработок по изменения ИС.
Как думаете, коллеги, будет ли эффективной такая схема? Какие слабые места?
Спасибо!
Вот подметил все точно, в наблюдательности не откажешь, сам замечаю что большинство изменений информационных систем, особенно на базе 1С, забывается уже через несколько использований и потом не возвращаются к нему. В этом полностью согласен. А если в реале существует даже и подсистема СИФА - ссылку в студию пожалуйста, за такое не пожалею и 5 стартмани!
Но вот переход про собственника (А что за завод, на котором программист с собственником может пообщаться? Завод по производству шавермы?) уже вызвал недоумение, выводы про всякие "Я" и вовсе непонятно что и зачем. Потому что наблюдения и анализ ситуации явно эмпирические, а выводы - фантастические. Как их использовать непонятно. Ну, может я тупой просто, не догоняю...
Одна надежда, на интересные мысли в комментариях, если повезет... )))
Я вот думаю, что причиной внесения любых изменений в ИС должна быть экономическая целесообразность: если полученный эффект превышает затраты на разработку - делаем. Даже если это будет одноразовая обработка или отчет.
Тут многим внутренним заказчикам надо уяснить, что программист не бесплатный. Даже если это программист штатный и на фиксированном окладе. И пока он делает им очередную хотелку, выхлоп от которой три копейки, а затраты на рубль - он в этот момент НЕ ведет разработку вещей у которых затраты на рубль, а выхлоп на тысячу. Причем бремя оценки экономической целесообразности должно ложиться на руководителей отделов Заказчика и Разработки, они совместно должны оценивать и составлять список доработок по изменения ИС.
Как думаете, коллеги, будет ли эффективной такая схема? Какие слабые места?
Спасибо!
(13)
Слабое место будет как раз-таки в оценке размере этого самого "выхлопа". Не всегда ведь все так просто, что одна доработка оценивается на 3 копейки, а вторая на тысячу целковых. "Выхлоп" может зависеть от многих факторов, хотя бы от того же, насколько эффективно люди будут пользоваться твоими доработками. Можно сделать супер-систему, способную увеличить продажи в 4 раза, но если никто ей пользоваться не будет, то какой толк? А это уже человеческий фактор. Об этом и говорится в статье.
Если мы говорим исключительно о внутренних разработках и их очереди, то тут, на мой взгляд, самый правильных подход, это живая очередь поставленных задач, степень их сложности (простые можно сделать быстро без очереди), распоряжения руководства (конкретно вот эту задачу нужно сделать срочно). Слишком близко принимать к сердцу реальную полезность своих разработок лучше не стоит - сплошное расстройство. Можно такие "неудачные решения" оценивать как работу на будущего работодателя.
Как думаете, коллеги, будет ли эффективной такая схема? Какие слабые места?
Слабое место будет как раз-таки в оценке размере этого самого "выхлопа". Не всегда ведь все так просто, что одна доработка оценивается на 3 копейки, а вторая на тысячу целковых. "Выхлоп" может зависеть от многих факторов, хотя бы от того же, насколько эффективно люди будут пользоваться твоими доработками. Можно сделать супер-систему, способную увеличить продажи в 4 раза, но если никто ей пользоваться не будет, то какой толк? А это уже человеческий фактор. Об этом и говорится в статье.
Если мы говорим исключительно о внутренних разработках и их очереди, то тут, на мой взгляд, самый правильных подход, это живая очередь поставленных задач, степень их сложности (простые можно сделать быстро без очереди), распоряжения руководства (конкретно вот эту задачу нужно сделать срочно). Слишком близко принимать к сердцу реальную полезность своих разработок лучше не стоит - сплошное расстройство. Можно такие "неудачные решения" оценивать как работу на будущего работодателя.
(13,14)Люди, которые потратили определенные усилия для отстаивания своей точки зрения о необходимости той или иной разработки в процессе дебатов, как правило, либо сами в конце концов от нее отказываются, публично признавая ее бесполезность, либо проникаются чувством значимости своей идеи и опосредованно чувством своей собственной значимости, причем опять-таки признанной публично. В этом случае ее использование гарантированно.
(13)Для того, чтобы избавить программиста от "хотелок", нужна коллегиальность в принятии решений, нужна система обоснований. И сам программист должен выступить в качестве инициатора такого подхода, уйдя таким образом от роли пассивного исполнителя и войдя в роль участника "коллегии" по принятию решений. Там, где удается это реализовать - затрат действительно меньше, а выхода - больше.
Эффективность связана с разделением труда, например в Макдональдс нет выделенных уборщиц, иначе пролитое кофе или рассыпанный попкорн оставались бы таковыми до закрытия кафе, снижая удовлетворение очередного посетителя, спрос и выручку.
Соответственно большой моющий пылесос как на вокзале им не нужен, а нужны 6 миксеров и крышечки на стаканчики. Хотя моющий пылесос дешевле всего этого в целом.
Вывод - совмещение должностей и освоение смежных специальностей повышает удовлетворение клиентов, и даже привлекает новых, если речь идет о сарафанном радио.
Но если рядом с Макдональдс вместо автозаправки откроется, например, детский дом...
Соответственно большой моющий пылесос как на вокзале им не нужен, а нужны 6 миксеров и крышечки на стаканчики. Хотя моющий пылесос дешевле всего этого в целом.
Вывод - совмещение должностей и освоение смежных специальностей повышает удовлетворение клиентов, и даже привлекает новых, если речь идет о сарафанном радио.
Но если рядом с Макдональдс вместо автозаправки откроется, например, детский дом...
А если в реале существует даже и подсистема СИФА
В реале таких воз и маленькая тележка.
Та же подсистема БСП: оценка производительности. Позволяет мерять время ключевых операций.
Во всех типовых формах встроены замеры.
Соответственно, если записи в регистре "замеры времени" появляются - сразу видно кто и как использует ту или иную функцию.
Мало того, замеры можно встроить вообще везде небольшой модификацией - хоть на каждый чих и кнопку.
ОценкаПроизводительностиКлиент.НачатьЗамерВремени();
ОценкаПроизводительностиКлиент.ЗавершитьЗамер();
аналогично на сервере
или типа того.