Этот кошмарный внутренний софт
Posted: октября 6, 2008 | Author: Андрей Шкуропий | Filed under: Разработка софта | Tags: банк, внутреннее ПО, внутренний софт, качество, кошмарное ПО, кошмарный софт, ошибки, плохой интерфейс, программное обеспечение | 20 комментариевВнутреннее программное обеспечение — это ПО, которое используется только внутри конкретной организации или группы организаций для выполнения относительно узкого круга задач. Обычно внутренний софт разрабатывают сами предприятия в отделах автоматизации, а потом внедряют на рабочих местах по команде сверху. Иногда внутренний софт заказывают сторонним подрядчикам, предварительно проводя тендер.
Этот софт всегда является отвратительной дешевкой. Я не видел еще ни одного экземпляра внутреннего ПО, при использовании которого мне не хотелось бы разбить клавиатуру об голову его программиста.
В большинстве случаев эти мысли возникают у всех пользователей такого софта, и работники массово пытаются избежать его использования, если предоставляется хоть малейшая возможность это сделать. Потому что без внутреннего ПО задача, для которой его создали, решается обычно на порядок быстрее и проще обычными бюрократическими методами, т.е. перекладыванием и переписыванием бумажек.
Внутреннее ПО обладает несколькими характеристиками, которые меня доводят больше всего:
- Масса логических ошибок.
Когда я работал администратором в банке, то внутреннее ПО создавало мне кромешный ад на земле, потому что в нем происходили сбои каждый час. При этом клиенты недополучали проценты по вкладам, счета сбрасывались в ноль, а огромные суммы денег при переводе терялись или подвисали в воздухе, не доходя до центрального сервера. Конечно, потом, в конце банковского дня, все деньги находили и доставляли по назначению, благодаря тому, что каждая операция, слава богу, дублировалась в бумажном виде, но все это ощутимо сказывалось на моих нервах и добавляло седины на голове.
Попытки указать разработчикам на ошибки и заставить их исправить, к сожалению, ничего не дали. Вместо этого предлагалось воспроизвести магическую последовательность действий с файлами, нажать несколько неприметных кнопок, пританцовывая с бубном, и ошибка обходилась. Когда я приехал увольняться в областной филиал (это был один из самых счастливых дней моей жизни), ребята-программисты показали мне тот самый шаманский бубен, и сказали, что без него работа банка была бы невозможна.
- Морально устаревший пользовательский интерфейс.
Вызывает смех сквозь слезы, когда организация закупает новейшие компьютеры с многоядерными 64-разрядными процессорами, 20-дюймовыми TFT-мониторами и предустановленной Windows XP OEM, а потом на них запускают 16-разрядное ПО от Васи Пупкина из второго отдела в окне MS-DOS и текстовом режиме 80х25. Это малюсенькое окошко одиноко торчит в углу экрана (не все знают, что надо нажать Alt+Enter для его максимизации), и людям приходится вводить данные в кошмарные текстовые формы с псевдографикой, которые были лучшим образцом юзабилити в 1985 году. Конечно, без использования мышки и без возможности скорректировать введенную информацию.
Для внутренних программ под Windows похожая история: они все созданы без каких бы то ни было минимальных удобств для пользователя. Я лезу на стену и вою от ужаса, когда вижу системы, построенные на Clarion и Visual FoxPro. Их сразу можно распознать по уродским формам для ввода данных, которые предназначены для каких-то зомби с вывихнутым мозгом, но уж никак не для людей.
Еще один пример идиотской концепции интерфейса — все виденные мною системы разделения доступа во внутренних приложениях. Когда-то, в конце восьмидесятых — начале девяностых годов, в СНГ сложился стиль разработки ПО с расчленением приложения на задачи-оверлеи. Каждая такая «задача» запускалась в отдельном окне, в котором она принимала команды от пользователя, делала что-то с данными из локальной БД и клала их обратно. Разделение доступа заключалась в том, что создавалось огромное меню задач, и каждому пользователю давался доступ только на определенное их подмножество. Меню обычно хранилось в текстовом файле на каждом рабочем месте, и администратору безопасности, чтобы расширить/ограничить кому-то разрешения, приходилось оббегать все компьютеры, вручную внося исправления в эти текстовые файлы, «закомментировав» несколько строк. Защитить саму базу данных (будьте прокляты, тысячи dbf-ок!) не представлялось возможным, и она регулярно убивалась нечаянными действиями пользователей. Спасали только частые резервные копии. С тех пор в архитектуре внутреннего софта ничего не изменилось. Факт того, что сейчас рулят многозвенные клиент-серверы и веб-интерфейсы, разработчикам внутреннего ПО совершенно неизвестен.
- Абсолютная негибкость конфигурации.
Очень мало или совсем нет параметров внутреннего софта, которые можно изменить для повышения удобства работы пользователя. У программиста почему-то никогда не возникает мысль, что условия на рабочих местах могут отличаться от того, на котором он пишет программу. Разрешение экрана — только 800х600, ни пикселя больше. Битов на пиксель — только 8, ведь 256 цветов — это очень даже много. Каталог, в который должна быть установлена программа — только «C:\ARM\», даже не обсуждается. Веселье начинается, когда две программы должны быть установлены в каталог C:\ARM\, потому что это очень популярное название. Экспорт данных — только на дискету под буквой «А:», пожалуйста, потому что выходное устройство намертво забито в исходном коде, а исходный код программист-пенсионер унес с собой в могилу. Я видел, как несчастные пользователи работали с такой программой, не вынимая дискету из дисковода, используя ее как промежуточный буфер между базой данных и сетевой папкой. Иногда после экспорта данных из приложения дискета не считывалась, поэтому приходилось ее форматировать и повторно запускать процесс экспорта с предварительной настройкой в течение получаса.
- Невозможность понять, как это работает, без непосредственного общения с программистом.
Является как следствием трех предыдущих тезисов, так и следствием отсутствия вразумительной документации. Если документация и прилагается к программе, то она построена в стиле, который я называю «нате, отцепитесь», когда ее пишут только «для галочки» и не предполагают, что ее будет кто-то читать. По крайней мере, понять концепцию работы программы по ней можно очень редко. Поэтому прямая связь с разработчиком программы или с каким-нибудь опытным пользователей становится архиважной. Авторы ПО, обычно, очень не любят, когда им звонят и спрашивают, как пользоваться их программой, ведь для них все очевидно, и они не понимают, как можно быть таким тупым и этого не понимать. Следовательно, при каждой попытке заинтересованных пользователей разобраться происходят скандалы между отделами с последующим коллективным распитием валидола.
- Невозможность самому разработать альтернативное, лучшее ПО.
Если вы — молодой энтузиаст и более-менее умеете программировать, то, когда вы будете ежедневно сталкиваться с кривым внутренним софтом, у вас обязательно возникнет идея переписать это уродство с нуля. Для типичного внутреннего ПО при хорошей университетской подготовке это займет у вас до одного-двух месяцев работы, и вы можете решить, что это замечательная альтернатива тому, чтобы мучаться с существующим ПО постоянно.
Однако, при попытке сделать это возникнут непредвиденные проблемы. Вы не сможете получить информацию, необходимую для безболезненного перехода всей организации на вашу программу (описания форматов данных, файлов экспорта/импорта для нормальной работы со смежными системами, полей любимых всеми dbf-файлов и др.), потому что никто из программистов ничего этого не документировал, а просто держал в голове. Если программист, создавший ПО, еще работает в организации, он вряд ли будет настроен на сотрудничество с вами, потому что вы автоматически станете его конкурентом в продвижении на следующую должность. Не у каждого энтузиаста хватит терпения докапываться с помощью дизассемблера до сути процессов, происходящих внутри.
К тому же, вы на всех уровнях организации будете встречать сопротивление вашим инновациям, потому что в любом коллективе есть пассивный балласт старых работников, которые изучили внутренний софт давным-давно, еще при старом программисте, написавшем его. Они не захотят переучиваться, даже если ваша программа в 100 раз лучше и надежнее, и это доказано тестированием.
Почему внутренний софт такой?
Причины, в общем-то, очевидны:
- Программисты не заинтересованы в качестве своего продукта.
Большинство программистов в отделах автоматизации работают на фиксированной ставке со смехотворными премиями. У них нет никакого финансового стимула делать софт качественно. Если у программиста и есть внутренняя мотивация «сделать хорошо», то она существует недолго. Почему-то так получается, что чем больше организация, тем меньше каждый человек хочет для нее выкладываться.
- Внутреннее ПО не разрабатывает молодежь.
Молодые талантливые программисты, которые могут делать качественные программные системы, не хотят работать в занюханных информационных отделах, сопровождающих электронный документооборот заводов, государственных структур, банков и других крупных предприятий. Хе-хе, если бы я был талантливым программистом, то не писал бы весь этот негатив в блоге, а работал бы на классную софтверную компанию, которая делает коммерческое ПО. В результате такими отделами в массе заправляют престарелые программисты «старой школы», которые начинали с разработки программ для компьютеров, а не для людей.
- Если внутреннее ПО заказывают на стороне, то на него тратят минимально возможные средства.
Поскольку любой отечественный бизнесмен хочет получать максимальную прибыль в краткосрочной перспективе, ему обычно наплевать на качество заказанного софта, если тот хоть как-нибудь решает поставленную задачу. Ведь не он же будет им пользоваться, в конец концов. Государственному управленцу тем более на это наплевать, потому что его не интересует вообще ничего. Поэтому тендеры на разработку софта выигрывают обычно те компании, которые предлагают много функций за меньшую цену, и никто не будет рассматривать вблизи, как именно эти функции реализованы. К тому же, если даже для заказных программ предприятие по документам выделяет вроде бы достаточно большой бюджет, очень часто конечные разработчики получают из этих денег мизерную долю. Вам слово «откат» говорит что-нибудь? Коррупция играет здесь не последнюю роль, да.
Вы можете спросить: «Автор, ты зачем все это рассказываешь? Мне вот все это было и так понятно, но я не думаю, что об этом стоит беспокоиться, ведь низкое качество внутреннего ПО — это вполне естественно, и тут ничего не поделаешь».
Я думаю, беспокоиться стоит. Плохой внутренний софт — это как айсберг, у которого самая опасная часть скрыта от наружного наблюдения. И когда ваша компания на него налетит, то вы даже не поймете, почему потонули.
Так зачем нужно улучшать внутреннее ПО?
Ответ на этот вопрос очевиден для служащих организации, которые круглосуточно матерятся, пытаясь заставить этот чертов внутренний софт работать. Совсем по-другому обстоит дело в кругах руководящего состава, который этот софт заказывает, распоряжается его бюджетом и принимает его после разработки. Именно для них приведу три веские (на мой взгляд) причины, почему важно его качество.
- Некачественный софт усиливает текучку кадров.
Когда у вас будет увольняться очередной работник, который, сидя за компьютером, постоянно нервничал и от злости иногда даже хлопал по монитору, потрудитесь спросить у него, что именно скрывается за формулировкой «по собственному желанию». Вполне возможно, что на 70—80% его недовольство рабочим местом было связано именно с плохо работающими программами. Пять особенностей внутреннего ПО, которые я описал выше, могут довести вполне спокойного человека до бешенства и нервного срыва, я сам это многократно видел воочию. А нервные срывы каждый день отнюдь не создают комфортных условий для работы.
- Некачественный софт снижает эффективность работы сотрудников.
Если у вас в приемной выстраиваются длиннющие очереди клиентов к «девочке с компьютером», то это говорит об одном из двух: либо девочка — тормоз, либо тормозом является ее программа, которая не позволяет делать быстрый ввод данных (есть еще и третий вариант, когда тормозом являются и девочка, и ее программа, но мы его здесь рассматривать не будем). Хорошо спроектированный пользовательский интерфейс позволяет заводить информацию в систему на порядок быстрее, чем плохо спроектированный. Вывод: за одно и то же время можно обработать больше клиентов и получить с них больше денег.
- Вы будете терять деньги из-за ошибок софта.
Когда слетает центральная база данных и работа всего предприятия приостанавливается на неопределенное время, вы теряете деньги. Когда ваш сайт взламывают малолетние хакеры-самоучки, и клиенты вместо коммерческого предложения видят чью-нибудь задницу на весь экран, вы теряете деньги и престиж. Если программа неправильно сводит баланс, или использует неточные формулы, это еще куда ни шло, вы даже можете не заметить потерь при большом денежном обороте. Хуже будет, если эти потери заметят ваши клиенты, которые мало того, что прекратят у вас обслуживаться, так еще и всем друзьям об этом расскажут.
Если какая-то программа является основой технологического процесса организации, то повышенные затраты на ее качественную разработку окупаются всегда. Понимание этого — одно из оснований коммерческого успеха и залог хорошего эмоционального микроклимата на рабочих местах.
Но рядовым работникам тоже следует учитывать влияние дрянного ПО на их жизнь. Когда вы будете устраиваться на новую работу, и ваша должность предполагает интенсивное взаимодействие с компьютером, при собеседовании обязательно спросите, какие программы будут у вас установлены. Требуйте посмотреть на них вблизи перед тем, как подписывать контракт. Никакая, даже самая большая зарплата не стоит вашего психического здоровья. Перетерпеть ежедневный контакт с плохой программой могут далеко не все, поверьте мне.
Ну, не везде и не все так плохо, как кажется
Я с 2003 года занимаюсь разработкой внутреннего софта для ЮКОСа (теперь уже для Роснефти) и могу сказать, что многие из указанных причин к моим продуктам не относятся… Хотя возможно здесь дело в том, что в основном весь внутренний софт все-равно разрабатывается на коммерческой основе (по договору с головной организацией).
Ну хоть где-то начальство думает про людей.
Начальники-идиоты, конечно, спишут все на то, что у “ЮКОСА немеряно денег”, но разработка хорошего заказного софта стоит не так уж и много, как может показаться, и эти расходы окупаются.
платите нормальные деньги, и все будет! и программеры начнут работать и пользователи не будут мучиться. А то как обычно делается – наймем за три копейки студентов и напишем свою операционку и потом удивляемся – и чтоже все такое кривое и не работает совсем… Не побоюсь открыть америку – хороший софт стоит немалых денег и включает в себя не только тупое написание кода…
Серж,
да, это нам с вами понятно. Жаль, не доходит до старшего менеджмента почему-то.
Eto reshaetsya prosto. Nuzhno pravilno upravlyat etim processom. Kto im upravlyaet v etih predpriyatiyah i kak? Ya sebe predstavlyayu…
Статья полная чушь! набрали неудачные примеры разработки софта и сейчас показывают что все так плохо… За частую внутренний софт заточен по организацию и ни одна программа стороннего разработчика не заменит ее без существенной доработки. Дос=программы используются лишь потому что они проверены временем и работают как часы, а новое ставить во первых дорого, во вторых внедрение занимает времени (от года до 5 лет а то и дольше). Просто пользователю не видно огромного количества всех внутренних механизмов и кроме как сказать свалить свою некомпетентность на кого то другого, а особенно на “программиста этой дурацкой программы” это милое дело..
Когда читал про молодых и талантливых – долго смеялся…
Вы сами-то видели таких? Или Вы лукавите, или Вы считаете, что сами – моложой и талантливый.
Обычно, тех людей, которые говорят, что давайте я лучше перепишу с нуля этот софт, вместо поддержки старого – надо сразу-же гнать в шею. Потому, что это диагноз – перфекционизм. И если его не вылечить, то этот “молодой и талантливый” будет постоянно переписывать и переписывать. А результата будет ноль.
Потому, что главное в софте – это работать с тем качеством, которое требует заказчик. При этом добиваться большего качества – это чистые убытки.
Про старые программы – на западе, насколько мне известно, старые программы меняются только уже тогда, когда нет возможности их сопровождать (нет разработчиков, нет компьютеров и пр.), а до этого момента деньги, которые вложены в эту разработку продолжают работать и приносить компании прибыль.
В общем и целом – статья с претензией на истину в последней инстанции. В каждым утверждением по поводу т.н. “некачественного” софта можно спорить. Но смысла спорить не вижу, т.к. правоту показывает рынок, который работает с этим софтом и не особенно напрягается. Я думаю, что проблему старого самописного софта надо решать не с позиции разработчика, а с позиции директора, которому нужно выбирать, куда направлять свободные средства – в развитие бизнеса, либо в переписывание программ, которые пусть не идеально, но работают. Это банальные приоритеты.
Дмитрий, а я, кстати, не сваливаю ответственность на программистов, если вы заметили. Если вас статья задела за живое, потому что вы один из писателей этого говнософта, ну что ж, простите, сказал, что думал.
Тут ведь не в том проблема, что пользователь дурак, а в том, что программисту наплевать на качество софта.
Николай, а вы наверное старый и бесталанный пенсионер.
> Обычно, тех людей, которые говорят, что давайте я лучше перепишу с нуля этот софт, вместо поддержки старого – надо сразу-же гнать в шею
Обычно поддержка старого софта невозможна по той простой причине, что исходник потерян. В четырех организациях, где я поработал, так и было. Вы скажете, что “выборка нерепрезентативна”, но я не знаю как там у вас в “прекрасном далеко” с этим дело обстоит, пишу про свое болото.
> статья с претензией на истину в последней инстанции
да, я так все время пишу. На моем блоге все – мое субъективное мнение, если непонятно.
Вы, кстати, повторили то, что я сказал в статье:
> Я думаю, что проблему старого самописного софта надо решать не с позиции разработчика, а с позиции директора, которому нужно выбирать, куда направлять свободные средства
Хе-хе… Андрей, я не пенсионер, но уже и не разработчик – поэтому так однозначно говорить, что если софт писан пусть даже и на DBF – его надо переписать.
При невозможности поддержки софта по причине потери кода, доков и пр., надо в первую очередь налаживать принципы работы разработчиков. Иначе написав новую программу компания окажется точно в таком-же положении – ни кода, ни доков – ничего.
И последнее – по поводу коммерческой составляющей – я еще раз повторюсь, что на уровне программиста/администратора многое не видно. И говорить, что однозначно надо переписывать тот или иной софт программист не может. Просто в силу ограниченности своего видения текущей ситуации в компании.
И переписать все это – это утверждение максималиста.
>переписать все это – это утверждение максималиста.
Действительно. Администратору и пользователям гораздо проще в этом случае найти другую работу и не напрягаться, настраивая существующее уродское ПО.
Переписать ведь можно с умом, проводя нормальное предпроектное исследование, тестирование, пошаговое внедрение нового с сохранением существующего софта, с совместимостью форматов данных и с возможностью вернуться на старый софт, если новый не удовлетворит. За один день никто организацию на новый АРМ перевести не сможет, конечно. Но попытаться можно, если не мешать программистам, которые хотят что-то изменить, а помочь и направить их.
Не видел еще ни одного ИТ-отдела, где шло бы нормальное эволюционное развитие программных систем. Всегда есть мега-авторитет-начальник, который один раз написал все ПО в организации еще во времена DOS, и он почему-то никогда не заинтересован в улучшении ПО, т.к. “его все полностью удовлетворяет”. Если бы еще остальных сотрудников удовлетворяло. Но ему проще и приятнее обзывать молодых специалистов перфекционистами и подсмеиваться в кулак, ничего не делая и для развлечения ставя им палки в колеса.
Андрей, еще раз повторюсь, что Ваш взгляд – это взгляд разработчика (т.е. извините, снизу).
Я могу сказать, что волю в такой ситуации, а тем более свободу действий разработчику надо давать очень и очень аккуратно. Например, я практически не видел самомотивируемых на результат (а результат, повторюсь – это работа программы с заданным уровнем качества) разработчиков. В большинстве это или энтузиасты, которые готовы вечно вылизывать код, либо люди, которые готовы работать, если есть четкое ТЗ.
Да и такое понятие: “работа программы с уровнем качества не выше требуемого” обычно звучит для разработчика как святотатство.
Захотел еще добавить про удовлетворение других сотрудников…
Я могу сказать, что внедрение новой системы чревато появлением такого количества проблем, что любой здравомыслящий руководитель очень долго подумает, что ему важнее – недовольство нескольких девочек на вводе данных (которых заменить в сущности не проблема) или проблемы, которые могут привести вплоть к остановке бизнеса.
Николай, а кто должен определять требуемый уровень качества? Никто ведь насильно не заставляет “сделай не лучше, чем на 3 балла по 6-балльной шкале”. Устанавливаются сроки сдачи проекта, и все, что программисты успели сделать в этот срок по ТЗ и будет требуемым уровнем качества (если требования ТЗ реализованы полностью). Но почему-то в ТЗ никогда не указывают, что программа должна быть удобной, т.к. это требует проработки пользовательского интерфейса, а за это никто не хочет доплачивать. В итоге реализуют все функции, которые в ТЗ описаны, но ни одной из них нельзя пользоваться без содрогания.
Я даже не говорю о какой-то сверхсложной оптимизации интерфейсов с тщательным юзабилити-тестированием, а об элементарных вещах, которые изучают в университетском курсе технологии программирования UI (например, при нажатии кнопки Tab фокус ввода должен переходить между элементами управления слева направо и сверху вниз, а не наоборот; для каждого состояния системы должен существовать операционный контекст, в котором можно делать определенные действия, но нельзя делать другие и т.п.).
Кто может помешать программистам применить эти элементарные знания, если они у них есть? Может, все упирается в ограничения используемой платформы (DOS+FoxPro против .NET 2.0, набор DBF-файлов против хорошей серверной СУБД и др.)?
что ему важнее – недовольство нескольких девочек на вводе данных (которых заменить в сущности не проблема) или проблемы, которые могут привести вплоть к остановке бизнеса
Остановка бизнеса также может произойти, если текучка кадров будет такой, что ни одна новая девочка не сможет оставаться на рабочем месте дольше 2 месяцев. Может, руководству и наплевать на своих людей (люди, между прочим, это чувствуют очень хорошо), но если сложить время+деньги на обучение нового персонала каждые два месяца, то год за годом будет набегать очень внушительная сумма. Еще никто не удосуживается подсчитать эффективность работы с программой и отдачу в денежном эквиваленте.
Плохие программы, конечно, не так заметно бьют по бизнесу, как глобальные экономические кризисы, но качественные программы ощутимо повышают доходы.
Андрей, я не знаю Вашего возраста, но поверьте мне, от того, на какой платформе написана программа – для пользователя практически ничего не зависит. И в досе пишут нормальные программы и использование DBF оправдано, когда нет необходимости в таком монстре, как SQL-сервер.
Кто Вам сказал, что технология .Net лучше для бизнеса, чем DOS+FoxPro? Именно это я и имел ввиду, что разработчика надо останавливать и все время бить по рукам, чтобы его не заносило. Ему всегда интересно применить что-то новое, изучить новую неотлаженную фишку и тут-же применить ее в программе. А старые программы дописывать – это увольте – это не мое.
Уж сколько раз проходил это.Все разговоры про отвратительный внутренний софт и то, что его надор срочно переписать с использованием новейших достижений програмистской мысли идут от разработчиков, которые просто не хотят работать.
Программист должен сам себя бить. По рукам, по башке. Пока не выбьет эту дурь из себя. Вот тогда он станет высококлассным специалистом. Который будет исходить прежде всего из требований заказчика, а не своих мифических задумок.
Текучка кадров на ресепшне или на приеме клиентов не так страшна. Девочек на рынке много.
Но Вы будете смеятся, когда увидите, что эффективность программы не оказывает практически никакого влияния на пользователей. А уж тем более не оказывает сколько-нибудь заметного влияние на бизнес. И знаете почему? Да потому, что 90 процентов пользователей не знают о кнопках таб, контрол-ентер и пр. Они как слепые котята. Не надо мерить пользователей по себе.
И еще, вы будете еще больше смеятся, когда спросите у людей, что им лучше, идти по бесконечному пути исправления программы или просто сделать корпоративный новый год. Думаю, Вы понимаете, что выберут люди.
PS
Переход по TAB должен происходить так, как это нужно для ввода той или иной формы и он может прыгать совсем не туда, куда указывает дизайнер.
Николай, мне 25.
Если кажется, что я максималист, то приглашаю вас поработать в любой банк, где стоят самописные АРМ, а потом сравнить с банком, где стоят нормальные программы управления банковским днем, которые купили за большие деньги. В банках второго типа почему-то совсем не нужны системные администраторы, которые бегают по офисам, как ошпаренные, и пытаются найти деньги, которые программа потеряла десятый раз за день.
Наверное, я пишу предвзято и необъективно, но я имею на это право, потому что натерпелся в свое время, перенес несколько служебных расследований и расплатился за чью-то экономию денег своим здоровьем. Я был прослойкой, которая смягчала все удары тупорылого софта по бизнесу.
Хотя, вы правы, на людей большому бизнесу наплевать, этого никто не изменит. Люди могут только выбрать лучшего работодателя, который будет их уважать и не будет заставлять работать на уродском ПО просто из-за жлобской экономии средств, которая в итоге приводит к большим затратам.
Насчет платформы. Новые платформы и новые средства разработки позволяют разрабатывать корпоративный софт на порядок быстрее и он будет на порядок надежнее, чем аналогичный софт, разработанный на старых технологиях. Я тоже раньше думал, как вы, что программисту вполне хватит знать хорошо свой любимый инструмент, и можно сделать с его помощью все, что угодно, но потом вот коллеги показали, что это не так. И многие вещи, для разработки которых требовались раньше немыслимые трудозатраты, с новыми технологиями решаются в пару строчек кода. А освободившееся время можно потратить на “социализацию” программы, приспособление ее к человеку и его потребностям, а не к потребностям компьютера. При этом никто не отменяет необходимость знания того, как что работает на нижних уровнях абстракции, но потери времени на разработку несоизмеримые.
Другое дело, что состоявшимся программистам лень изучать новые инструменты и технологии, просто потому что это не принесет им никаких выгод, ведь они уже “состоялись” и теперь им достаточно только сопровождать свой старый софт. При этом у молодежи тоже, конечно, надо на корню пресечь стремление к использованию “новых непроверенных технологий” просто чтобы самим не напрягаться. Вот лучше бы показали молодым, как организовывать процесс разработки, правильно ставить задачу, грамотно делать прототипирование, планирование, тестирование готового продукта и тысячу других вещей, которые нужны для разработки качественного софта. Но проще запретить и упразднить новые инструменты, конечно. Я понаблюдал за этим конфликтом “опытности” и “максимализма” в нескольких ИТ-отделах. Побеждали, конечно, всегда старые-”бывалые” ленивые ИТ-начальники, симбиоза не получалось никогда, а пользователи продолжали плеваться и тратили половину рабочего дня на коррекцию ошибок софта, который достиг пика развития, уперся в свой технологический потолок и способности этого “бывалого”.
На самом деле все зависит от уровня организации компании и ее масштабов, а так же насколько она современна.
Компании российского масштаба, работающие на территории всей россии, как правило для автоматизации основной деятельности используют внешние промышленные системы на основе Oracle OEBS (кстати интерфейс продуктов тоже не ахти), внутренний софт используется для автоматизации каких либо мелких подзадач. При этом большинство разработок делается под веб клиента на основе клиент-сервер. Качество же продукта определяется в основном: качетсвом технического задания, требованиями заказчика (в случае внешнего подразделения, а не ИТ), грамотностью и позицией ИТ руководителя и конечно квалификацией разработчика.
Молодые компании как правило не обремены глубоким наследием прошлого в виде Clipper, FOX PRO и DOS, все описанное в статье больше применимо с компаниям старой закалки и гос учереждениям, хотя и там начинаются подвижки.
Позвольте вставить пару строк от себя.
На новом месте работы как раз столкнулся самописным АРМом. Который, естественно, никто не сопровождает – его писали давным давно. Документации – никакой. Те кто с ней работают – не могут объяснить, что обозначают те или иные поля. Поэтому вопрос менять или не менять не стоял.
А шефу я объяснил очень просто. То что девочки вбивают – мне приходиться проверять и исправлять. Мне лениво разбираться в чужой неграмотности, замотанности и т.д. Мне проще создать новое, учитывая ошибки старого.
P.S. Сижу теперь, расписываю на бумаге что, как, сколько раз…
P.S. Честно предупредил шефа, что сам все не осилю. Надо будет привлекать. На что мне ответили – составляй смету. Составляю.
Пантеев Зорикто, удачи вам. Знакомая ситуация.