Импортозамещение-3

Получилось как бы в продолжение двух предыдущих заметок. 

Стараясь не вдаваться в подробности...

Тут один местный старожил говорил за импортозамещение, а в частности о программном обеспечении для конструкторов. Мне за последние пять лет удалось выкроить время на обучение дважды: первый раз на упомянутый в статье продукт, второй – на внедряемый у нас модуль управления жизненным циклом его конкурента, с конструкторской программой которого много лет работаю. Ни в том, ни в другом случае «лекторы» не смогли ответить на мои весьма несложные вопросы как относительно отсутствия естественных с точки зрения простого конструктора функций, так и касательно нелепых методов реализации новых функций, в особенности несоответствия стандартам.

К слову, предыдущая внедрённая у нас программа управления, как быстро выяснилось, была не в состоянии работать с обозначениями по принятой на предприятии нормали, потому что эта структура обозначения в системе жестоко зарезервирована под служебные нужды. В процессе выбора, закупки и внедрения ни один внедренец не пострадал не удосужился выяснить такую нелепую малость. Её допиливали десять(!) лет – безуспешно – и вот теперь решили поменять. Шило на мыло.

Это был взгляд с одной стороны.

А с другой стороны мне по работе приходится очень много иметь дело с программистами (другого прикладного направления) – наблюдать, так сказать, в естественной среде обитания, поэтому мне понятно откуда растут ноги у проблем современного прикладного программного обеспечения.

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

Сорок лет назад программист физически не мог быть гуманитарием. Чтобы составлять алгоритмы нужно было иметь недюжие технические познания не только относительно предмета алгоритмирования, но и не меньше (а порой и куда больше) относительно технических средств, на которых этому алгоритму предстояло исполняться. Опять же, задача оптимизации исполняемого кода лежала целиком и полностью на плечах программиста. Компетенции предъявлялись сразу – демонстрируемой оптимальностью процесса выполнения прикладной задачи. Программисты были технарями.

Это определяло набор непременных составляющих программирования, как то: а) глубокое погружение в алгоритмируемый процесс; б) необходимость жёстко оптимизировать выполнение; в) способ общения программы с оператором являлся лишь следствием выполняемых задач. Поэтому, когда чуть позже программы начали приобретать удобочитаемые для простого пользователя интерфейсы, они (интерфейсы) были поначалу крайне специфичны, страдая в части эстетики в угоду функциональности. Зато очень логичны для специалиста, для которого и были написаны.

Сегодня же мы имеем такую картину: оптимизацией занимается компилятор, как работают технические средства знают тысячи драйверов, интерфейс разобран на элементы и доступен для накликивания и т.д. Вроде бы уже всё сделано для того, чтобы программист не отвлекался на мелочи и мог положить все усилия на постижение предмета программирования и построение максимально предметной логики работы программы? Не в этой жизни.

Последние лет десять наблюдаю на ниве программирования неотвратимое замещение технарей гуманитариями. Гуманитарий-программист – ещё совсем недавно нонсенс – сегодня обыденность. Как следствие для нонешних программистов характерно: а) сложность в постижении истинного смысла алгоритмируемого процесса; б) красота буковок в коде важнее его оптимальности; в) интерфейс первичен, функциональность – лишь следствие приколов выбранной модели взаимодействия с пользователем.

Сегодняшние молодые программисты не знают как работает компьютер (вот эта чёрная коробка), не могут осилить ни одну техническую статью (ролик на трубе – максимум), категорически не умеют работать в команде без корпоративной накачки. Гуманитарии, мать их так.

Возвращаясь к импортозамещению: с САПР я работаю больше двадцати лет, последние пять-семь лет отечественные САПР стремительно валяться в тартарары – с каждым годом способы реализации новых функций всё более и более нелепы. Этому есть две причины. Одна описана выше. Вторая – менеджеры.

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

Кстати, в софтверной техподдержке тоже похожая фигня. Редкие технари, которые пытаются вникнуть в проблемы пользователей, и много гуманитариев, которые завсегда объяснят тебе, что ты просто тупой, поэтому у тебя всё плохо и ты сам себе злобный буратино. Вообще, большинство технарей считает гуманитариев хоть и странными, но всё же обучаемыми существами, а большинство гуманитариев уверено, что технари недалёки, неотёсаны и, следовательно, необучаемы в принципе. Поэтому объяснить гуманитарию, что он не прав, практически невозможно. Кроме того, технарь в компании гуманитариев будет вечно бит, потому что гуманитарии в большинстве своём агрессивны по отношению к тем, кто по факту в плане получения зримого результата оказывается способнее их. По этой же причине технически грамотные люди в коллективах с засильем гуманитариев не задерживаются – что тоже становится частью процесса деградации коллективов, и, как следствие, падения качества выполняемой этим коллективом работы.

И вот теперь я сижу и с ужасом думаю, что мне в конечном итоге придётся таки переходить на новую версию рабочего ПО, в которой по отношению к моей текущей версии гуманитарии-улучшатели убили как минимум пару своих конкурентных преимуществ. Просто потому, что кому-то показалось так правильно. Или, может быть, прикольно. На вопрос «зачем» ответ предельно однозначный: привлечение новых клиентов. Мнение старых уже никого не интересует – куда они, типа, денутся. И никто, собственно, даже не пытается скрывать ничего – все свои косяки знают. Просто никто не несёт за это никакой ответственности. А безнаказанность порождает вседозволенность. Вот как-то так.

Не смотря ни на что я являюсь последовательным сторонником отечественного конструкторского ПО, считаю его [пока ещё] лучшим в мире и очень надеюсь, что производители этого программного обеспечения разгонят к чёртовой матери гуманитариев, наберут технарей и найдут реальных компетентных конструкторов – реально работающих над самыми разными задачами – в качестве консультантов с реальными компетенциями. Тот, кто сможет это сделать – выдержит конкуренцию с кем угодно.

Тем, кто говорит, что нужно туда-то обращаться и тому-то писать – не утруждайте себя. Если вам повезло со своей местной техподдержкой на предприятии, то вам натурально повезло. Низкая компетенция техподдержки напрямую соседствует с гипертрофированным уровнем её самомнения – любые попытки как обращаться к ней, так и прыгать через её голову ничего, кроме потраченного времени и нервов не приносят. Единственным вариантом более-менее нормальной работы становится минимизация общения с такой техподдержкой в купе с минимизацией взаимодействия со всякими системами управления, внедряемыми такой техподдержкой. Столкнётесь – поймёте.

Гуманитарии – это не те люди, на которых стоит рассчитывать во времена передела Мира.

Высокотехнологичное импортозамещение: система T-FLEX-PLM (mamomot)

   Эта статья, уверен, заинтересует многих представителей инженерного и не только сообщества. Некоторые мои читатели знают, что я интересуюсь проблемами отечественных САПР. Чтобы моя критика разработчиков была конструктивной, я веду свой блог на главном форуме компании Топ-Системы, посвященного её продукту T-FLEX PLM, в теме: