Получилось как бы в продолжение двух предыдущих заметок.
Стараясь не вдаваться в подробности...
Тут один местный старожил говорил за импортозамещение, а в частности о программном обеспечении для конструкторов. Мне за последние пять лет удалось выкроить время на обучение дважды: первый раз на упомянутый в статье продукт, второй – на внедряемый у нас модуль управления жизненным циклом его конкурента, с конструкторской программой которого много лет работаю. Ни в том, ни в другом случае «лекторы» не смогли ответить на мои весьма несложные вопросы как относительно отсутствия естественных с точки зрения простого конструктора функций, так и касательно нелепых методов реализации новых функций, в особенности несоответствия стандартам.
К слову, предыдущая внедрённая у нас программа управления, как быстро выяснилось, была не в состоянии работать с обозначениями по принятой на предприятии нормали, потому что эта структура обозначения в системе жестоко зарезервирована под служебные нужды. В процессе выбора, закупки и внедрения ни один внедренец не пострадал не удосужился выяснить такую нелепую малость. Её допиливали десять(!) лет – безуспешно – и вот теперь решили поменять. Шило на мыло.
Это был взгляд с одной стороны.
А с другой стороны мне по работе приходится очень много иметь дело с программистами (другого прикладного направления) – наблюдать, так сказать, в естественной среде обитания, поэтому мне понятно откуда растут ноги у проблем современного прикладного программного обеспечения.
А ещё вот недавно читал одного продвинутого программиста с готовыми рецептами захвата вселенной здесь . В отличии от указанного мнения, мои наблюдения говорят скорее о процессе деградации, который (процесс) я наблюдаю, так сказать, в реальном времени.
Сорок лет назад программист физически не мог быть гуманитарием. Чтобы составлять алгоритмы нужно было иметь недюжие технические познания не только относительно предмета алгоритмирования, но и не меньше (а порой и куда больше) относительно технических средств, на которых этому алгоритму предстояло исполняться. Опять же, задача оптимизации исполняемого кода лежала целиком и полностью на плечах программиста. Компетенции предъявлялись сразу – демонстрируемой оптимальностью процесса выполнения прикладной задачи. Программисты были технарями.
Это определяло набор непременных составляющих программирования, как то: а) глубокое погружение в алгоритмируемый процесс; б) необходимость жёстко оптимизировать выполнение; в) способ общения программы с оператором являлся лишь следствием выполняемых задач. Поэтому, когда чуть позже программы начали приобретать удобочитаемые для простого пользователя интерфейсы, они (интерфейсы) были поначалу крайне специфичны, страдая в части эстетики в угоду функциональности. Зато очень логичны для специалиста, для которого и были написаны.
Сегодня же мы имеем такую картину: оптимизацией занимается компилятор, как работают технические средства знают тысячи драйверов, интерфейс разобран на элементы и доступен для накликивания и т.д. Вроде бы уже всё сделано для того, чтобы программист не отвлекался на мелочи и мог положить все усилия на постижение предмета программирования и построение максимально предметной логики работы программы? Не в этой жизни.
Последние лет десять наблюдаю на ниве программирования неотвратимое замещение технарей гуманитариями. Гуманитарий-программист – ещё совсем недавно нонсенс – сегодня обыденность. Как следствие для нонешних программистов характерно: а) сложность в постижении истинного смысла алгоритмируемого процесса; б) красота буковок в коде важнее его оптимальности; в) интерфейс первичен, функциональность – лишь следствие приколов выбранной модели взаимодействия с пользователем.
Сегодняшние молодые программисты не знают как работает компьютер (вот эта чёрная коробка), не могут осилить ни одну техническую статью (ролик на трубе – максимум), категорически не умеют работать в команде без корпоративной накачки. Гуманитарии, мать их так.
Возвращаясь к импортозамещению: с САПР я работаю больше двадцати лет, последние пять-семь лет отечественные САПР стремительно валяться в тартарары – с каждым годом способы реализации новых функций всё более и более нелепы. Этому есть две причины. Одна описана выше. Вторая – менеджеры.
Во время последнего обучения в полной мере ощутил чудовищную нелепость ситуации: перед внедрением нового модуля управления жизненным циклом на предприятии менеджеры обсуждают с менеджерами будущий регламент работы конструкторов! Лектор на обучении нам говорит «в нашей системе вариантов реализации этой функции много, у вас скорее всего будет так...» – и начинает объяснять последовательность действий, полностью противоречащую самому принципу работы предприятия. На вопрос «откуда эта дичь» ответ всегда один: такой регламент согласован с вашим руководством. То есть получается, что один человек менеджер, который ни разу не конструктор, рассказывает другому человеку менеджеру, который ни разу и не конструктор и не программист, как второй должен поставить задачу программистам, чтобы конструкторам первого не было скучно работать. При этом и первому, и второму абсолютно наплевать как всё есть на самом деле (они это, кстати, и не скрывают), потому что свои зарплаты они и так получат, а понять это «как надо» потребует от них чрезвычайных усилий, поскольку они тоже гуманитарии. Их не интересует результат, поскольку от результата не зависит их благосостояние. И ни один конструктор со своими дурацкими мыслями как сделать правильно никогда не будет иметь шансов против этих менеджеров. Потому что «чтобы быть рассмотренными, ваши замечания и предложения в службе технической поддержки должны набрать критическую массу» (это прямая цитата), а пожелания менеджера оплачиваются напрямую предприятием, которое этот менеджер представляет, и реализуются тут же как само собой разумеющиеся. Тот факт, что реализуемые в программе функции противоречат ГОСТ (хотя производитель утверждает обратное), а согласованный регламент в принципе противоречит СТО (какая мелочь), сам по себе противоречит здравому смыслу, что для гуманитария не представляется проблемой. Мы живём в эпоху дилетантов. Лет семь назад я даже текст такой написал – валяется где-то на компьютере. Надо бы найти.
Кстати, в софтверной техподдержке тоже похожая фигня. Редкие технари, которые пытаются вникнуть в проблемы пользователей, и много гуманитариев, которые завсегда объяснят тебе, что ты просто тупой, поэтому у тебя всё плохо и ты сам себе злобный буратино. Вообще, большинство технарей считает гуманитариев хоть и странными, но всё же обучаемыми существами, а большинство гуманитариев уверено, что технари недалёки, неотёсаны и, следовательно, необучаемы в принципе. Поэтому объяснить гуманитарию, что он не прав, практически невозможно. Кроме того, технарь в компании гуманитариев будет вечно бит, потому что гуманитарии в большинстве своём агрессивны по отношению к тем, кто по факту в плане получения зримого результата оказывается способнее их. По этой же причине технически грамотные люди в коллективах с засильем гуманитариев не задерживаются – что тоже становится частью процесса деградации коллективов, и, как следствие, падения качества выполняемой этим коллективом работы.
И вот теперь я сижу и с ужасом думаю, что мне в конечном итоге придётся таки переходить на новую версию рабочего ПО, в которой по отношению к моей текущей версии гуманитарии-улучшатели убили как минимум пару своих конкурентных преимуществ. Просто потому, что кому-то показалось так правильно. Или, может быть, прикольно. На вопрос «зачем» ответ предельно однозначный: привлечение новых клиентов. Мнение старых уже никого не интересует – куда они, типа, денутся. И никто, собственно, даже не пытается скрывать ничего – все свои косяки знают. Просто никто не несёт за это никакой ответственности. А безнаказанность порождает вседозволенность. Вот как-то так.
Не смотря ни на что я являюсь последовательным сторонником отечественного конструкторского ПО, считаю его [пока ещё] лучшим в мире и очень надеюсь, что производители этого программного обеспечения разгонят к чёртовой матери гуманитариев, наберут технарей и найдут реальных компетентных конструкторов – реально работающих над самыми разными задачами – в качестве консультантов с реальными компетенциями. Тот, кто сможет это сделать – выдержит конкуренцию с кем угодно.
Тем, кто говорит, что нужно туда-то обращаться и тому-то писать – не утруждайте себя. Если вам повезло со своей местной техподдержкой на предприятии, то вам натурально повезло. Низкая компетенция техподдержки напрямую соседствует с гипертрофированным уровнем её самомнения – любые попытки как обращаться к ней, так и прыгать через её голову ничего, кроме потраченного времени и нервов не приносят. Единственным вариантом более-менее нормальной работы становится минимизация общения с такой техподдержкой в купе с минимизацией взаимодействия со всякими системами управления, внедряемыми такой техподдержкой. Столкнётесь – поймёте.
Гуманитарии – это не те люди, на которых стоит рассчитывать во времена передела Мира.
Комментарии
Какое счастье, что я 10 лет тому назад спрыгнул со всего этого. Стёр у себя в башке всё и наслаждаюсь пенсией, с отвращением вспоминая прошлое.
Про себя этого сказать не могу.
До сих пор работаю и в теме.
Вам хорошо. Я сначала спрыгнул, потом вернулся.
В ужасе, но работаю, потому что как писал Хайнлайн "дороги должны катиться"
Раньше гуманитарием называли человека, который хорошо знал историю, литературу, иностранные и древние языки, а сейчас гуманитарием называют того, кто не осилил таблицу умножения.(с)
кто не прошёл по баллам в технический вуз
Я не прошёл в гуманитарный вуз... Пришлось идти в инженеры)
Как было бы по баллам не знаю. Егэ тогда не было) и попытка поступления была всего одна. Но так как я в школу пошёл в 6, у меня их было две)
Я имел в виду первых, но вторых сейчас больше.
Театр должен начинаться с вешалки!!! Тьфу - The Show Must Go On!!!
Гуманитарий придет за тобой!
В статье одна ошибка:
"нетехнарь" не равно "гуманитарий".
А примерно равно "работник, не соответствующий занимаемой должности". Краткий эквивалент по вкусу.
Нет. Гуманитарий и технарь - данности. От должности или соответствия не зависит.
Есть ещё ветеринары...
Это правда? Зп менеджера не связана с результатом его работы? По идее ж должна быть прямая зависимость
Правда. Иногда конечно в итоге через год его увольняют, но оставленные им руины так и так восстановлению практически не подлежат.
А иногда награждают. А после краха пожурят и оставляют переделывать всё заново, награждают, потом крах и дальше по кругу.
Вы - идеалист!
И точно не из ИТ
Возможно, я просто не совсем удачно использую практически нарицательное «менеджер». Пусть будет управленец. И зарплата его зависит от милости его начальства, а не от результата. Потому что его начальство - те же управленцы. Если бы его начальством были сугубо практичные технари, он бы ни дня не задержался на своём месте.
Для вычисления прямой зависимости и пропорционального награждения нужны метрики измерения трудового вклада. А их обычно либо нет, либо они не отражают реальность.
В 90х внедряли в одной торговой конторе софт, учитывающий все детали работы "продажников". И вскоре выяснилось, что по финансовым результатам лидирует вовсе не тот 40-летний гуру продаж, который считался недостижимым мастером, а молодой скромный паренёк, "на которого никто бы не подумал". Но ничего для этих двух работников не изменилось :)
Похоже
Из несколько сумбурного и достаточно эмоционального описания я понял, что в организации ТСа гуманитарий-руководитель поставил кривое техническое задание подрядчику, а гуманитарий-менеджер разработчиков не счёл должным перепроверять каждый нюанс ТЗ и отправил в разработку то, что заказали. Виноваты в этом гуманитарии-программисты.
Отвечу "с той стороны", как разработчик ПО. Проблема, как видится, в организации бизнес-процессов поддержки ПО.
Работаю по удаленке в 2-х конторах. В одной конторе все четко:
Организация поддержки: есть jira, в ней тикеты-саппорты, контроль задач по содержимому и времени, отчеты по завершению.
Бизнес-процесс поддержки: каждый тикет от заказчика изучается аналитиком, создается задача, отводится время на выполнение, задача мной решается, тестируется аналитиком и после тестируется и, бывает, возвращается заказчиком.
В другой конторе постановка задачи объясняется по скайпу, в формате "как бы эту штуковину засунуть вон в ту карточную форму?".
В обоих конторах менеджеры поддержки - технари. Так что думается, проблема не в "физиках-лириках", а в знаниях и компетенциях менеджеров поддержки ПО.
Если человек имеет техническое образование, это вовсе не значит, что он технарь по складу ума. Лучшие оценки по математике имеют зубрилы, а они, как правило, гуманитарии. То есть можно решать сложные задачи и иногда даже успешно не вникая в суть проблемы. Главное выучить алгоритмы.
Однозначно
На этот счёт вспомнил случаи. В клиенскои инженерной конторе (нефтянка) один специалист повесил плакат с высказыванием тогдашнего президента медведев а о том что качества не может быть много.
Начальник потребовал убрать и не позориться. Тот стал спорить.
И что меня удивило, то что мало кто понял что не так с этим плакатом... Почему начальник был возмущён.
А в чем там было дело? Почему начальник возмущался?
Ну речь шла о том что есть куча людеи которая не понимает сути своеи профессии, но просто выучили алгоритмы и решают задачки по ним много лет.
Вот поэтому я привёл этот случаи.
Инженер должен понимать что качества должно быть ровно столько нужно. И должен уметь определить сколько же нужно.
Потому что избыток качества - это ненужный расход ресурсов, денег и сил.
Пример. Во время второи мировои воины Англичане полировали броню своих танков.
Это и есть избыточное качество.
Или ещё пример. Современные самолёты су 35 идеальны тольео издалека. Вблизи они как будто молотком выбиты. Но ответственные с аэродинамическои точки зрения элементы "вылизаны". Западные самолёты вылизаны целиком.
Поэтому если инженер утверждает что качества не бывает достаточно, то он не понимает сути своеи профессии.
Да, техническая поддержка - это ужас-ужас-ужас (19 лет работаю в этой сфере, сам стараюсь с чужой тех-поддержкой не общаться, ибо в большинстве случаев это бесполезная трата времени). Причём глобально, это не какая-то российская специфика. Но даже при хорошо организованных безнес-процессах дело может упереться в бутылочное горлышко в виде нехватки разработчиков - их либо частично сократили после релиза продукта, либо они пилят уже запланированные (и зачастую уже опланченные!) на два года вперёд фичи, либо пытаются разгребать накопившийся бэклог.
Где то видел американскую статью в которои утверждал ось что чем успешнее дела у компании тем хуже у неё тех поддержка.
Причина банальная. Тех поддержка жрет средства и не приносит прибыли на этом этапе. Но вообще убрать её они не могут. Поэтому максимально удешевляют и делают неудобно.
То есть они просто её удешевляют. А забиваюшие на все малооплачиваемые сотрудники уже сами делают "неудобно"
У тех кто ещё не на коне она работает отлично потому что их прибыль напрямую зависит от каждого довольно го клиента.
Статью такую не читал, но давно пришел к таким же умозаключениям на основе собственного опыта. Тех-поддержка это расходная часть бюджета компании. Успешная компания имеет много клиентов => растёт нагрузка на поддержку и её начинают "оптимизировать" - организуют multi-line support (с моей точки зрения это отстой), в первые линии зачастую ставят ботов (сейчас еще нейросети прикрутят). Нанимать новый песонал тоже достаточно сложно и дорого, берут всех подряд или оутсорсят.
Как наглядный пример ZenDesk - в целом неплохой продукт, но техническая поддержка полный отстой. Критичные вопросы можно быстро порешать только с привлечением Account Manager'а, которого можно заполучить как отдельную платную опцию. При этом они не стремаются проводить различные семинары на тему "best-practices и современные тренды в технической поддержке" и т.п.
Ну собственно все тоже самое и есть
Ну собственно я и не спорил а даже наоборот :)
Более того, я могу рассказать еще больше деталей, проблем и их причин, однако здесь делать этого не буду - мне не очень понравилась рекация ТСа, возможно в каком-нибудь другом топике сподоблюсь.
Формально да
Нет
Ладно, не обижайтесь пожалуйста. Лично меня "стриггерила" дихотомия технари-гуманитарии и глобальные обобщения. В то же время я прекрасно вас понимаю - видно, что вы совершенно искренне переживаете за своё дело, а ситуация, в которую вас поставили и, главное, чувство бессилия что-то исправить кого угодно выведет из равновесия. Сам не раз попадал в такую ситуацию и зачастую вёл себя абсолютно безобразно.
Тем не менее, основной прокол я вижу именно на стороне вашего руководства - не собрали (или недостаточно качественно собрали) технические требования специалистов, кторым потом пришлось работать с сырой системой. Не предусмотрели в договоре периода, когда исполнитель будет обязан исправлять всплывшие недочёты (даже в очень хорошем ТЗ что-то да будет упущено). Также считаю неправильным, что вы вынуждены самостоятельно обращаться в техническую поддержку вместо того, чтобы просто поднять этот вопрос своему рукводству.
Это достаточно стандартный ответ - в большинстве случаев, сфера ответственности технической поддержки это уже имеющийся и заявленный функционал, в то время как улучшения и дополнения лежат вне их компетенции. Таких "замечаний и предложений" приходит великое множество, некоторые противоречат друг-другу, некоторые вообще какая-то дичь. Чтобы разобраться во всём этом у инженера тех-поддержки не хватает ни экспертизы ни мотивации - протолкнуть незапланированную фичу в разработку требует незаурядных усилий. В лучшем случае, они лишь могут правильно задокументировать ваше обращение и эскалировать выше по инстанции.
И да, это всё плохо и не правильно. Более того, ситуация со временем только ухудшается, в то время как сложность и критичность систем растёт. Так что, как закоренелый оптимист ответственно вам заявляю - хуже обязательно будет.
Мы в ЭНИМСе в конце 80-х занимались похожими проблемами.
Я написал диссертацию на тему проектирования шпиндельных коробок с действующей программой, которая работала и проектировала такую коробку.
На довольно слабых компьютерах PDP-11.
Никаких гуманитариев, разумеется, у нас не было.
Параллельно работали группы по ЧПУ и разработке универсальных программ для конструктора, типа, описанных в статье.
С упразднением станкостроения все это закрылось, программисты уехали или поменяли специализацию.
Считаю, что разработки такого рода должны вести инженеры-программисты по типу хирургической бригады, описанному ещё полвека назад
Никаких тимлидов с Битриксом.
И люди должны работать долго, а не меняться каждые три месяца.
Так ничего хорошего не выйдет.
И никакого Чубайса.
Только специалисты.
Последние пять строк - краткое резюме
А это ваша идея была, что затраты на автоматизацию не должны превышать прибыль от её внедрения?
И давайте про "взрыв сложности" чего-нибудь. Кошастый что-то такое знал и в деревню свалил из Киева в 2004 (!).
Нет
А про "полные вилы"?
http://unicornix.spb.ru/humor/heap08h.htm
Нет
вы так говорите как будто руководители команды или битрикс - это что-то заведомо плохое
про Чубайса впрочем полностью согласен )))
Да
Битрикс для управления программистами - однозначно плохое.
Руководить - не руками водить.
Руководить программистами может только программист.
Он принимает код, делает окончательную проверку и переносит код в актуальный релиз.
И только он отвечает потом за программу.
А не девочка с улицы, нанятая по объявлению.
И никаких Битрикс.
Пусть программист удаленно делает, что хочет и когда хочет.
Но к установленному сроку предоставь код, который будет тут же проверен.
Это и есть руководство.
Сокращает количество программистов, участвующих в разработке, в разы.
Да
Сам не имею отношения к ай ти, но плотно общаюсь с ними. Лет 20 назад работал с ними, и сейчас общаюсь.
Один рассказывал что самый лучшии начальник у него был ноль в программировании. Даже азов не знал.
Но знал как ясно и чётко поставить задачу, и какои результат надо получить и кто это лучше это сделает. По специальности начальник был какои то технарь, но не программист.
Соответствующий склад ума
Ну да. Но ещё я сомневаюсь что он совсем уж ноль был)
Такого начальника при случае можно сократить без вреда для производства.
А для программиста такой начальник, разумеется, лучше.
Можно лапшу ему на уши вешать.
Если человек не дурак то вряд ли
Если человек не дурак, то он не возьмется руководить шахматистами, не умея играть в шахматы.
Страницы