Comments 26
Одной из самых частых причин графомании некоторые исследователи называют гиперкомпенсацию комплекса неполноценности, а часть случаев — выражением бредовой или сверхценной идеи идентификации себя с выдающимся писателем…Вики.
Графомания встречается при некоторых формах шизофрении, паранойе, маниакальном и гипоманиакальном состояниях, и при других психических расстройствах. При синдроме психического автоматизма (Кандинского — Клерамбо) больные могут говорить, что их вынуждают много писа́ть некие внешние силы. Графоманические тенденции нередки у сутяжных психопатов (при параноидном расстройстве личности).
Есть такое понятие — стоимость ошибки.
— иногда стоимость ошибки не видна сразу;
— иногда стоимость ошибки специально скрывается, чтобы попробовать изменение;
— и в любом из таких случаев — стоимость ошибки ложиться не на «бизнес-программиста», а на владельца;
— учитывая сложность производств, сложность ИТ, сложность процессов, некий «пропагандон» даром убеждения или иными мотивами, может добиться со стороны decision maker нужного ему решения, но ту надо понимать, что всем чем рискует тот самый бизнес-программист. так это своим местом, а вот владельцы рискуют серьезными средствами; т.о. — только прототипирование, только pre-prod, только анализ, никаких таких кавалерийских наскоков в духе илона_маска (если за вами не стоит наса, прав-во сша и деньги инвесторов);
— и наконец, автоматизация это всегда сопутствующее (если мы не про бизнес в ит), а не основное средство производства, имеет вторичныеполовые финансовые признаки (попробуйте пожалуйста оспорить с цифрами на примере нефтегаза), поэтому, ставить во главу угла мифического бизнес-программера — мифически глупо. Как-бы не было обидно бизнес-програмеру.
— иногда стоимость ошибки не видна сразу;
— иногда стоимость ошибки специально скрывается, чтобы попробовать изменение;
— и в любом из таких случаев — стоимость ошибки ложиться не на «бизнес-программиста», а на владельца;
— учитывая сложность производств, сложность ИТ, сложность процессов, некий «пропагандон» даром убеждения или иными мотивами, может добиться со стороны decision maker нужного ему решения, но ту надо понимать, что всем чем рискует тот самый бизнес-программист. так это своим местом, а вот владельцы рискуют серьезными средствами; т.о. — только прототипирование, только pre-prod, только анализ, никаких таких кавалерийских наскоков в духе илона_маска (если за вами не стоит наса, прав-во сша и деньги инвесторов);
— и наконец, автоматизация это всегда сопутствующее (если мы не про бизнес в ит), а не основное средство производства, имеет вторичные
По-моему во главу ставят не бизнес-программиста, а изменения процесса. И изменять советуют понемного, чтобы цену ошибки снизить. Для производства и заводских процессов (сталелитейного например) нужнен уже жестко зарегламентированный фронт работ. Здесь про небольшие изменения.
Да много всяких понятий есть.
Во главу угла ставятся реальные, быстрые и полезные изменения. Если перечисленные вами термины как-то помогают этой цели достигать — прекрасно.
Во главу угла ставятся реальные, быстрые и полезные изменения. Если перечисленные вами термины как-то помогают этой цели достигать — прекрасно.
А что мешает пробовать сначала на тестовой системе?
а смысл? Бизнес-процесс изменен в реальной жизни, а работать люди будут в тестовой системе? Зачем?
Для проверки.
Изменили попробовал, поправили, ещё раз проверили.
Если понравилось переносим в рабочую систему.
Не нужно откатывать из рабочей не понравившиеся изменения.
Изменили попробовал, поправили, ещё раз проверили.
Если понравилось переносим в рабочую систему.
Не нужно откатывать из рабочей не понравившиеся изменения.
А с данными как быть?
Так тестовая же система — не замена рабочей.
Ну. Чтобы проверить качество изменения процесса, поддержанного автоматизацией, нужно выполнять измененный процесс, поддержанный автоматизацией. При использовании тестовой системой вы не можете этого делать — данных или нет, или они не актуальны.
В результате вы не можете протестировать свой процесс. И просто становитесь в очередь на автоматизацию. Гипотеза, выдвинутая при изменении процесса, будет проверена черт знает когда. И будет ли вообще. И изменений не будет.
В результате вы не можете протестировать свой процесс. И просто становитесь в очередь на автоматизацию. Гипотеза, выдвинутая при изменении процесса, будет проверена черт знает когда. И будет ли вообще. И изменений не будет.
автор изобретает свой правильный срам?
правильный скрам я изобрел два года назад. Статья не об этом.
Более правильный чем был придуман до вас?
Не тот ли где вы описывали поминутную тарификацию для программистов?
Не тот ли где вы описывали поминутную тарификацию для программистов?
как я понял, в статье излагается подход a la agile, только в применении к бизнес-процессам: выкатывай рано и небольшими порциями, лажай быстро, чтобы, в случае необходимости, быстро откатить. как оно называется — дело десятое.
UFO just landed and posted this here
В большинстве случаев, после изменения процесса, вам требуется автоматизация – надо внести правки в информационную систему. Если вы скажете – нужно техническое задание, план-график, проект с руководителем, куратором и спонсором, то – все.
Ёклмн… Если вы официальный работник фирмы, вы руководитель ИТ-отдела, и вы предлагаете изменения, то ТЗ пишете вы подчиненным. А не кто-то вам.
Вот тут и нужен принцип быстрой автоматизации.
Для этих целей и придумали Скрам.
Sign up to leave a comment.
Тяп-ляп и в продакшн? Почему бы и нет