Pull to refresh

Comments 34

Не так категорично. Зачастую бизнес и IT меняются местами. Сам бизнес (бюрократия) тормозит IT (изменения). Но история правдивая, надо таких посылать.
Задумался. Походу я сам в таком же заводе ЖБИ работаю…

Получается, что всё что строк написаны ради двух слов: Автоматизация изменений?


Надеюсь, что всё-таки будет продолжение с примерами и техническими подробностями, а так же опытом внедрения.

К середине текста я догадался, кто автор. Автор, жги еще!
Может, чересчур эмоционально и с перегибами, но по наболевшему.

Я так понял, это про необходимость гибкой разработки в реалиях быстроизменяющихся требований. На эту тему есть концепция экстремального программирования — чтобы писать код, устойчивый к изменениям требований. Ну а автоматизация изменений — это уже из области нейросетей)

Писать код, устойчивый к изменениям — долго.
А бизнес хочет здесь и сейчас.

Сделать быстро можно только оставляя технический долг, который потом и приводит к гигантским затратам финансов и времени.
Когда-нибудь бизнес поймет, что дешево и быстро сейчас — это дорого и долго потом. И со временем всё дороже и дольше, пока однажды кто-то не сделает, наконец, рефакторинг)

Бизнес никогда этого не поймет.
В бизнесе выигрывает тот, кто выкатывает продукт быстрее.
Нытье про то, что «Ой, как дорого поддерживать», оно не от того, что бизнес хочет сделать хороший софт, оно от того, что бизнес хочет чтобы и поддержка была дешевой.
И рыбку съесть и костью не подавится. Но этого не будет. потому что приоритет всегда в выкатывании решения быстро. Отсюда всякие continuous integration и прочие техники нацеленные исключительно на быстрое выкатывание.
Когда-нибудь бизнес поймет, что дешево и быстро сейчас — это дорого и долго потом

Дело в том, что это миф. Бизнес — это в большинстве случаев не какие-то глупые ребята, которые не понимают разницу в качестве между дешево и быстро и дорого и медленно. Как правило, они занимаются тем же, чем и ИТ, продают свои услуги или товары другим клиентам, и точно так же конкурируют качеством и скоростью решения проблем. И логично ожидать, что они ждут этого самого от ИТ.
И вот тут самое интересное: лет… надцать назад программисты за 300-500 баксов/месяц решали их проблемы быстро, а теперь программисты за 50 баксов/час почему-то их решают медленно, с кучей сопутствующих бумажек и всяких дополнительных трат.
Естественно, бизнес начинает задумываться, а в чём подвох. Ему рассказывают что-то про архитектуры, управление требованиями, изменениями, эджайл и т.д., а он чувствует, что его где-то пытаются развести на деньги, особенно учитывая тот факт, что консалтинг-то получает повременную оплату, а не фиксированную за коробочку с софтом.
И самое неприятное в том, что эти вот ощущения бизнеса зачастую его не обманывают. Дешевый софт — это как неофициальные картриджи для принтеров. Да, служит зачастую хуже, чем официальный. Но если собрать все риски, если выбрасывать на помойку в несколько раз чаще, чем решение от «официалов», все равно суммарный экономический эффект будет выше.
Так проблемы другие были. Автоматизировать учёт на автомойке с помощью ёкселя — это одно. Автоматизировать учёт и управление в автосервисном холдинге с 100 теруправлениями и 500 точками в каждом теруправлении — немного другое.
Но для бизнеса — тыжпрограммист, вчера нам за 300 баксов в месяц автомойку автоматизировал.
Ну это же частный случай. 99% случаев автоматизации — это не холдинги с 100 теруправлениями, а как раз мелкий и средний бизнес. Которые по своим потребностям в автоматизации не так чтоб уж и далеко ушли от возможностей ёкселя/аксеса.
Вот они и просит, мы же не далеко ушли, напишите нам свой акссес или эксель.
Ну так и тут. Нужно периодически выбрасывать на помойку.
Т.е. или сразу пишем дорого, или пишем не слишком дорого, но регулярно рефакторим( что буде безусловно дороже чем сразу дорого, но размазано по времени ), или периодически выбрасываем на помойки и пишем с нуля.
К сожалению когда бизнесу предлагают эти три варианта развитие событий становится предсказуемым.
Бизнес выбирает или два или три, но не принимая окончательного для себя решения. Т.е. мы выбрали вариант с рефакторингом, не потому, что так риски ниже( вдруг в нулевой точке мы сильно ошибемся ), принимая, что так дороже, а потому что реафкторинг это когда-нибудь потом, при этом потом никогда не наступает.
Система становиться монстром, ит начальник привыкает слышать, «потом», и просто уже перестает запрашивать паузу на рефакторинг.
Как результат или поддержка становиться атомной и все делают вид, что все ок, или всех собак вешают на ИТ начальника, его меняют, новому на небольшой срок дают кучу ресурсов, дальше все возвращается на круги своя, пока не наймут внешнюю команду, которая сделает опять тоже самое, дальше разорвут отношения с внешней командой и опять возьмут своих и по новому кругу.
Если выбрали вариант три, выкидывать и считать прототипом, опять таки никто ничего не выкидывает, и все сваливается к варианту два.
Именно что — бизнес, пройдёмте. Кто полгода назад божился, что схема закупки будет одна на все времена? Кто сказал — сделайте быстро, с маленьким бюджетом, незачем планировать возможность изменений, когда изменения произойдут, тогда и посмотрим? Кто кричал — нам нужен новый сайт, стильный, модный, молодёжный, а в ответ на робкое «зачем» орал ещё громче — «не рассуждать! работать!»?
Кто говорил — мы небольшая компания, нам не нужен большой штат IT, тыжпрограммист, ты один со всем справишься?
А теперь у них, видите ли, IT-отдел неповоротливый. Теперь им блокчейн не нравится, хотя указание по блокчейну спустил сам генеральный, со словами «сегодня уже все банки на блокчейне, завтра будет вообще всё на блокчейне, одни мы останемся в жопе, быстро переводите на блокчейн».
— Извини, конечно, это я сгоряча. Ну и думал, что ты неадекватный, и будешь до конца морду гнуть и строить из себя важного хрена.
И да, кто потребовал чтобы сайт сделали за шесть копеек три студента на новомодном фреймворке, который они знали только потому что делали на нем курсовую, и теперь это древность как отходы мамонта, без всякой совместимости с любыми системами, кроме как через экспорт-импорт текстовых файлов? И не надо щас брызгать слюной, мы же помним почему студенты слились — им заплатили только три копейки из шести, указав что сайт не печатает банкноты и не делает сам себе раскрутку в яндексе и гугле.
экспорт-импорт текстовых файлов

иногда это лучшее что можно ожидать от движка
IT-отдел делает то, что ему сказали и так как сказали.
А как сказали? БЫСТРЕЕ, ДЕЛАЙ БЫСТРЕЕ!
И да, сделанное быстро в аврале потом очень дорого поддерживать.
Ты – мастодонт, питекантроп, старое вонючее ископаемое, работающее методами прошлого тысячелетия.

а варианты то какие? аутсорс — 21 век? в интеграции крупных проектов в аутсорсе можно погрязнуть уже в бюрократии на согласовании интеграции пары пустяковых функций
==
понятно что бизнесу пофиг на особенности реализации, но это жизнь такая и от нее не убежишь, можно сколько угодно плакать что ИТ тормозит бизнес, но бизнес не будет работать без этого мастадонта… уже проходили такое, забивают на ИТ и начинают считать в экселе (а чо… две девочки из бухгалтерии и менеджмента обсчитают всю экономику быстрее чем запрограммить ERP, класс!)… потом через пару лет спохватываются что в гигабайтах экселя и самопальных инструментов ничего нельзя найти, а люди это начинавшие давно уволились и начинается перевнедрение первоначальной неповоротливой и ненужной системы… и далее по кругу
ИМХО это просто жизненный цикл любого бизнеса, рано или поздно в нем начинают превалировать внутреннии издержки и процессы, над внешними раздражителями. В разных частях бизнеса это происходит с разной скоростью. Как быстро проявиться данное явление зависит от менеджмента, начиная с самого верхнего уровня.
Не бывает бизнеса «на кончиках пальцев» который менеджменту на блюде принес ИТ, не бывает и все.
На кончиках пальцев может быть только очень маленький бизнес, крошечный.
Все уровни менеджмента делают, то что умеют, то за что не ругают, то за что не надо отвечать и то за что гладят по голове( ну или из чего можно лично себя, что-то поиметь ). Они очень быстро адаптируются к неявным требованиям внутри компании или просто из нее вымываются.

Любые изменения, это ответственность, если это не проращивают с самого верхнего уровня, допуская возможность ошибки, раскидывая в разные стороны деньги( именно раскидывая, потому что не ясно где и что взойдет ), поддерживая нововведения на всех уровнях, ломая или выкидывая закостеневшие структуры и не допуская клановости и своячничества, давая всем участникам процесса на изменения необходимые ресурсы и награждая всех участников изменений, уменьшая неизбежную бюрократию, то все подразделения будут «бетонироваться».
Отлично, отлично. Ну т.е. бизнес действует в духе «быстро мне запилил новый вариант автоматизации !» — но отвечать потом за последствия изменений будет ИТ. Нарисовать, согласовать ТЗ, бизнес-процессы, DR — это всё лишняя и ненужная бюрократия, работать надо уже вчера!
Знакомо, очень знакомо.
А потом мы читаем высказывания того же Грефа, что им лично согласованная и утвержденная модернизация ИТ — это вчерашний день, и надо это выкидывать. Ну, просто как пример.
Бизнес хочет изменений? Не вопрос! ИТ-службы к этому готовы, я бы сказал — всегда. Проблема в том, что бизнес не хочет а)нести затраты, необходимые для автоматизации желаемого и б) нести за это ответственности. Вот как раз бюрократия — она именно в таких условиях и возникает, как средство оградить людей от ответственности за то, в чем они — по должности, что характерно — разбираться и не обязаны. Не хотите бюрократии? Так не переносите на ИТ ответственность за провалы в бизнес-решениях, да и всё. Для начала.
Внутренняя же бюрократия ИТ нужна — и она, кстати, особенных каких-то накладных расходов не создает: у проблемы должны быть фамилия и имя.
Было несколько идей об собеседнике бизнеса, не угадал, ну точнее угадал но только за пару фраз до того как он был открыт автором :)
Бизнес сначала требует кнопку «Сделать всё», а потом удивляется — почему так дорого переделать кнопку, чтобы она работала при новых бизнес-процессах!
Строим 10-этажный дом, а потом: «Нам надо чуть-чуть увеличить высоту потолков на 1 этаже, там делов — на полкирпича». Но, как ни странно, в этом случае нужен новый дом.
Информационная система — это дом, где одно зависит от другого.
Информационная система — это дом, где одно зависит от другого.

Информационная система — это не дом. Это информационная система. В ней одно зависит от другого, но утверждать, что в неё сложно вносить изменения — это ложь. Некоторые изменения вносить сложно. Но в общем случае изменить процесс, добавить статусы, шаги, новое поведение кнопки, форму, новый бизнес-процесс — всё это штатные операции, которые никакой rocket science не предполагают, и не требуют перестройки всёй архитектуры. А если требуют, то чаще от того, что или архитектура фиговая, или консультант плохо трансформировал требования заказчика в концепцию продукта.
> — Сколько, по-твоему, надо времени людям, которые занимаются закупом, чтобы перестроиться и начать работать по новой схеме?
> — Хм, даже не знаю. Сколько?
> — По факту – один час. Они уже это сделали.
> — Что-то не верится в такие чудеса…
> — Потому я тебе и говорю честно, открыто и прямо: иди в жопу.

А я бы пошёл. Написал бы заявление, и пошёл бы к другому радже, побогаче тебя.
Есть неплохая книга про бетон, преобразование бизнеса и автоматчицы изменений. Не так категорично, но на конкретном примере. Называется «проект феникс»

очень похоже на диалог государственных регуляторов и бизнеса

Как по мне тут кроется краеугольный камень бизнеса, который сам же бизнес не понимает. Чем больше компания, тем больше издержки по ее управлению, больше информации которую нужно хранить и обрабатывать и нужны совсем другие методы и инструменты, тяжелые и неповоротливые. 1я ступень зрелости — стартап, тут достаточно карандаша и тетрадки чтобы делать все — вести бухгалтерию, документировать продукт, учитывать кто сколько отработал и т.д. А можно вообще в голове держать, если память хорошая. Дальше уже больше сотрудников памяти 1го человека не хватает, тетрадка заканчивается очень быстро и смотреть в нее уже нужно нескольким людям а физически она в одном месте, а нужна она в разных и одновременно. Вот тут подключают IT отдел, трекинговую систему свою Wiki, бухгалтерскую систему. Все это желательно бесплатное, и обычно гибкое, костыляется скриптами иногда падает, но ведь простой 3-5 человек из-за упавшей на час другой системы — это не так дорого. Растем дальше, у нас уже 50-100 человек, и тут уже IT отдел понимает, что в случае чего простой будет у 60-80 человек и систеа обросла костылями и падает чаще и 1 час такого простоя обходится в 1-2 тыс. долларов для компании. В месяц набегает 10-20 тысяч, вот IT это понимает, а бизнес — нет. Спрашивается почему??? Бизнес кричит хочу гибкость хочу плюшки. Расходы от простоя растут, IT изо дня в день бьются с одними и теми же проблемами, бонусов уже давно не видели, потому как этот бюджет съеден падающими сервисами и простоями. Но бизнес же хочем гибкости, а не вложений в стабильную работу. Мотивация падает ниже плинтуса и начинается самый веселый этап — "текучка". И тут понеслось, бизнес кричит хочу быстро, поэтому документации минимум. Старые люди и знания уходят, приходят новые, которым никто не может объяснить как это все работает их бросают на монстра из костылей и без документации и говорят "в бой". В результате этот костыльный мостр загибается под собсвенной тяжестью один раз упавши и не в силах больше подняться.
Господа "бизнес", я вас очень прошу почитайте PMBoK, 2ой этап зрелости компании — бюрократизация и документация, плюс стабилизация систем и стандартизация инструментов. Цель этого этапа ликвидировать критические точки, т.е. людей чей уход однозначно ведет к краху компании. Его нужно просто пережить, лучше помогите своей компании его пережить и выйти дальше в масштабируемость.

Когда начал читать, начало складыватся впечатление что автор описывает не далекое будущее Российского бизнеса, где бизнесс-процессы берет под контроль государство и начинается бюрократия, где каждое изменение нужно согласовывать с государством. Автор, Вы хоть намекайте в начале статьи о чем рассказ, а если бы не дочитал, собрал вещи и дернул бы из России подальше...(шутка)
где бизнесс-процессы берет под контроль государство

Я весь текст только так и думал/понимал — только из комментов узнал, что речь о чем-то ином…
Ибо примерно с подобным со стороны гос-ва уже который год сталкиваюсь, не по бизнесу, но подобное имеет место быть.
Думаете, было бы лучше, если бы намекнул в начале? Получилась бы скучная статья о том, что «надо хорошо работать».
Сталкивался с похожим где-то в 2015:
Был целый IT-отдел в продуктовом ритейле, пилили разные штуки важные и глобальные. Но внести изменения было долго и сложно, поэтому некоторые функции просто не отдавали айтишникам, а пилили сами исполнители — на VB:
Продуктовая сеть на несколько регионов, а ежедневный заказ на поставку товара несколько лет шёл по схеме: выгрузка таблички в access из mssql — передача в vb-прогу с интерфейсом для управляющего, потом в эксельку результат и на сетевой диск, откуда её потом собирал mssql.

В то же время, бывают it-отделы, которые не могут никак через бюрократию пробиться и сделать всё по уму…
Sign up to leave a comment.

Articles