Comments 34
Донцова, перелогиньтесь ))
Получается, что всё что строк написаны ради двух слов: Автоматизация изменений?
Надеюсь, что всё-таки будет продолжение с примерами и техническими подробностями, а так же опытом внедрения.
Может, чересчур эмоционально и с перегибами, но по наболевшему.
Я так понял, это про необходимость гибкой разработки в реалиях быстроизменяющихся требований. На эту тему есть концепция экстремального программирования — чтобы писать код, устойчивый к изменениям требований. Ну а автоматизация изменений — это уже из области нейросетей)
А бизнес хочет здесь и сейчас.
Сделать быстро можно только оставляя технический долг, который потом и приводит к гигантским затратам финансов и времени.
Когда-нибудь бизнес поймет, что дешево и быстро сейчас — это дорого и долго потом. И со временем всё дороже и дольше, пока однажды кто-то не сделает, наконец, рефакторинг)
В бизнесе выигрывает тот, кто выкатывает продукт быстрее.
Нытье про то, что «Ой, как дорого поддерживать», оно не от того, что бизнес хочет сделать хороший софт, оно от того, что бизнес хочет чтобы и поддержка была дешевой.
И рыбку съесть и костью не подавится. Но этого не будет. потому что приоритет всегда в выкатывании решения быстро. Отсюда всякие continuous integration и прочие техники нацеленные исключительно на быстрое выкатывание.
Когда-нибудь бизнес поймет, что дешево и быстро сейчас — это дорого и долго потом
Дело в том, что это миф. Бизнес — это в большинстве случаев не какие-то глупые ребята, которые не понимают разницу в качестве между дешево и быстро и дорого и медленно. Как правило, они занимаются тем же, чем и ИТ, продают свои услуги или товары другим клиентам, и точно так же конкурируют качеством и скоростью решения проблем. И логично ожидать, что они ждут этого самого от ИТ.
И вот тут самое интересное: лет… надцать назад программисты за 300-500 баксов/месяц решали их проблемы быстро, а теперь программисты за 50 баксов/час почему-то их решают медленно, с кучей сопутствующих бумажек и всяких дополнительных трат.
Естественно, бизнес начинает задумываться, а в чём подвох. Ему рассказывают что-то про архитектуры, управление требованиями, изменениями, эджайл и т.д., а он чувствует, что его где-то пытаются развести на деньги, особенно учитывая тот факт, что консалтинг-то получает повременную оплату, а не фиксированную за коробочку с софтом.
И самое неприятное в том, что эти вот ощущения бизнеса зачастую его не обманывают. Дешевый софт — это как неофициальные картриджи для принтеров. Да, служит зачастую хуже, чем официальный. Но если собрать все риски, если выбрасывать на помойку в несколько раз чаще, чем решение от «официалов», все равно суммарный экономический эффект будет выше.
Но для бизнеса — тыжпрограммист, вчера нам за 300 баксов в месяц автомойку автоматизировал.
Т.е. или сразу пишем дорого, или пишем не слишком дорого, но регулярно рефакторим( что буде безусловно дороже чем сразу дорого, но размазано по времени ), или периодически выбрасываем на помойки и пишем с нуля.
К сожалению когда бизнесу предлагают эти три варианта развитие событий становится предсказуемым.
Бизнес выбирает или два или три, но не принимая окончательного для себя решения. Т.е. мы выбрали вариант с рефакторингом, не потому, что так риски ниже( вдруг в нулевой точке мы сильно ошибемся ), принимая, что так дороже, а потому что реафкторинг это когда-нибудь потом, при этом потом никогда не наступает.
Система становиться монстром, ит начальник привыкает слышать, «потом», и просто уже перестает запрашивать паузу на рефакторинг.
Как результат или поддержка становиться атомной и все делают вид, что все ок, или всех собак вешают на ИТ начальника, его меняют, новому на небольшой срок дают кучу ресурсов, дальше все возвращается на круги своя, пока не наймут внешнюю команду, которая сделает опять тоже самое, дальше разорвут отношения с внешней командой и опять возьмут своих и по новому кругу.
Если выбрали вариант три, выкидывать и считать прототипом, опять таки никто ничего не выкидывает, и все сваливается к варианту два.
Кто говорил — мы небольшая компания, нам не нужен большой штат IT, тыжпрограммист, ты один со всем справишься?
А теперь у них, видите ли, IT-отдел неповоротливый. Теперь им блокчейн не нравится, хотя указание по блокчейну спустил сам генеральный, со словами «сегодня уже все банки на блокчейне, завтра будет вообще всё на блокчейне, одни мы останемся в жопе, быстро переводите на блокчейн».
— Извини, конечно, это я сгоряча. Ну и думал, что ты неадекватный, и будешь до конца морду гнуть и строить из себя важного хрена.
А как сказали? БЫСТРЕЕ, ДЕЛАЙ БЫСТРЕЕ!
И да, сделанное быстро в аврале потом очень дорого поддерживать.
Ты – мастодонт, питекантроп, старое вонючее ископаемое, работающее методами прошлого тысячелетия.
а варианты то какие? аутсорс — 21 век? в интеграции крупных проектов в аутсорсе можно погрязнуть уже в бюрократии на согласовании интеграции пары пустяковых функций
==
понятно что бизнесу пофиг на особенности реализации, но это жизнь такая и от нее не убежишь, можно сколько угодно плакать что ИТ тормозит бизнес, но бизнес не будет работать без этого мастадонта… уже проходили такое, забивают на ИТ и начинают считать в экселе (а чо… две девочки из бухгалтерии и менеджмента обсчитают всю экономику быстрее чем запрограммить ERP, класс!)… потом через пару лет спохватываются что в гигабайтах экселя и самопальных инструментов ничего нельзя найти, а люди это начинавшие давно уволились и начинается перевнедрение первоначальной неповоротливой и ненужной системы… и далее по кругу
Не бывает бизнеса «на кончиках пальцев» который менеджменту на блюде принес ИТ, не бывает и все.
На кончиках пальцев может быть только очень маленький бизнес, крошечный.
Все уровни менеджмента делают, то что умеют, то за что не ругают, то за что не надо отвечать и то за что гладят по голове( ну или из чего можно лично себя, что-то поиметь ). Они очень быстро адаптируются к неявным требованиям внутри компании или просто из нее вымываются.
Любые изменения, это ответственность, если это не проращивают с самого верхнего уровня, допуская возможность ошибки, раскидывая в разные стороны деньги( именно раскидывая, потому что не ясно где и что взойдет ), поддерживая нововведения на всех уровнях, ломая или выкидывая закостеневшие структуры и не допуская клановости и своячничества, давая всем участникам процесса на изменения необходимые ресурсы и награждая всех участников изменений, уменьшая неизбежную бюрократию, то все подразделения будут «бетонироваться».
Знакомо, очень знакомо.
А потом мы читаем высказывания того же Грефа, что им лично согласованная и утвержденная модернизация ИТ — это вчерашний день, и надо это выкидывать. Ну, просто как пример.
Бизнес хочет изменений? Не вопрос! ИТ-службы к этому готовы, я бы сказал — всегда. Проблема в том, что бизнес не хочет а)нести затраты, необходимые для автоматизации желаемого и б) нести за это ответственности. Вот как раз бюрократия — она именно в таких условиях и возникает, как средство оградить людей от ответственности за то, в чем они — по должности, что характерно — разбираться и не обязаны. Не хотите бюрократии? Так не переносите на ИТ ответственность за провалы в бизнес-решениях, да и всё. Для начала.
Внутренняя же бюрократия ИТ нужна — и она, кстати, особенных каких-то накладных расходов не создает: у проблемы должны быть фамилия и имя.
Строим 10-этажный дом, а потом: «Нам надо чуть-чуть увеличить высоту потолков на 1 этаже, там делов — на полкирпича». Но, как ни странно, в этом случае нужен новый дом.
Информационная система — это дом, где одно зависит от другого.
Информационная система — это дом, где одно зависит от другого.
Информационная система — это не дом. Это информационная система. В ней одно зависит от другого, но утверждать, что в неё сложно вносить изменения — это ложь. Некоторые изменения вносить сложно. Но в общем случае изменить процесс, добавить статусы, шаги, новое поведение кнопки, форму, новый бизнес-процесс — всё это штатные операции, которые никакой rocket science не предполагают, и не требуют перестройки всёй архитектуры. А если требуют, то чаще от того, что или архитектура фиговая, или консультант плохо трансформировал требования заказчика в концепцию продукта.
> — Хм, даже не знаю. Сколько?
> — По факту – один час. Они уже это сделали.
> — Что-то не верится в такие чудеса…
> — Потому я тебе и говорю честно, открыто и прямо: иди в жопу.
А я бы пошёл. Написал бы заявление, и пошёл бы к другому радже, побогаче тебя.
очень похоже на диалог государственных регуляторов и бизнеса
Как по мне тут кроется краеугольный камень бизнеса, который сам же бизнес не понимает. Чем больше компания, тем больше издержки по ее управлению, больше информации которую нужно хранить и обрабатывать и нужны совсем другие методы и инструменты, тяжелые и неповоротливые. 1я ступень зрелости — стартап, тут достаточно карандаша и тетрадки чтобы делать все — вести бухгалтерию, документировать продукт, учитывать кто сколько отработал и т.д. А можно вообще в голове держать, если память хорошая. Дальше уже больше сотрудников памяти 1го человека не хватает, тетрадка заканчивается очень быстро и смотреть в нее уже нужно нескольким людям а физически она в одном месте, а нужна она в разных и одновременно. Вот тут подключают IT отдел, трекинговую систему свою Wiki, бухгалтерскую систему. Все это желательно бесплатное, и обычно гибкое, костыляется скриптами иногда падает, но ведь простой 3-5 человек из-за упавшей на час другой системы — это не так дорого. Растем дальше, у нас уже 50-100 человек, и тут уже IT отдел понимает, что в случае чего простой будет у 60-80 человек и систеа обросла костылями и падает чаще и 1 час такого простоя обходится в 1-2 тыс. долларов для компании. В месяц набегает 10-20 тысяч, вот IT это понимает, а бизнес — нет. Спрашивается почему??? Бизнес кричит хочу гибкость хочу плюшки. Расходы от простоя растут, IT изо дня в день бьются с одними и теми же проблемами, бонусов уже давно не видели, потому как этот бюджет съеден падающими сервисами и простоями. Но бизнес же хочем гибкости, а не вложений в стабильную работу. Мотивация падает ниже плинтуса и начинается самый веселый этап — "текучка". И тут понеслось, бизнес кричит хочу быстро, поэтому документации минимум. Старые люди и знания уходят, приходят новые, которым никто не может объяснить как это все работает их бросают на монстра из костылей и без документации и говорят "в бой". В результате этот костыльный мостр загибается под собсвенной тяжестью один раз упавши и не в силах больше подняться.
Господа "бизнес", я вас очень прошу почитайте PMBoK, 2ой этап зрелости компании — бюрократизация и документация, плюс стабилизация систем и стандартизация инструментов. Цель этого этапа ликвидировать критические точки, т.е. людей чей уход однозначно ведет к краху компании. Его нужно просто пережить, лучше помогите своей компании его пережить и выйти дальше в масштабируемость.
где бизнесс-процессы берет под контроль государство
Я весь текст только так и думал/понимал — только из комментов узнал, что речь о чем-то ином…
Ибо примерно с подобным со стороны гос-ва уже который год сталкиваюсь, не по бизнесу, но подобное имеет место быть.
Был целый IT-отдел в продуктовом ритейле, пилили разные штуки важные и глобальные. Но внести изменения было долго и сложно, поэтому некоторые функции просто не отдавали айтишникам, а пилили сами исполнители — на VB:
Продуктовая сеть на несколько регионов, а ежедневный заказ на поставку товара несколько лет шёл по схеме: выгрузка таблички в access из mssql — передача в vb-прогу с интерфейсом для управляющего, потом в эксельку результат и на сетевой диск, откуда её потом собирал mssql.
В то же время, бывают it-отделы, которые не могут никак через бюрократию пробиться и сделать всё по уму…
Бизнес, пройдемте…