Этот кошмарный внутренний софт

21.02.2009 03:00 Автоматизация
Печать

Внутреннее программное обеспечение — это ПО, которое используется только внутри конкретной организации или группы организаций для выполнения относительно узкого круга задач. Обычно внутренний софт разрабатывают сами предприятия в отделах автоматизации, а потом внедряют на рабочих местах по команде сверху. Иногда внутренний софт заказывают сторонним подрядчикам, предварительно проводя тендер.

Этот софт всегда является отвратительной дешевкой. Я не видел еще ни одного экземпляра внутреннего ПО, при использовании которого мне не хотелось бы разбить клавиатуру об голову его программиста.

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

Внутреннее ПО обладает несколькими характеристиками, которые меня доводят больше всего:

1. Масса логических ошибок.

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

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

2. Морально устаревший пользовательский интерфейс.

Вызывает смех сквозь слезы, когда организация закупает новейшие компьютеры с многоядерными 64-разрядными процессорами, 20-дюймовыми TFT-мониторами и предустановленной Windows XP OEM, а потом на них запускают 16-разрядное ПО от Васи Пупкина из второго отдела в окне MS-DOS и текстовом режиме 80х25. Это малюсенькое окошко одиноко торчит в углу экрана (не все знают, что надо нажать Alt+Enter для его максимизации), и людям приходится вводить данные в кошмарные текстовые формы с псевдографикой, которые были лучшим образцом юзабилити в 1985 году. Конечно, без использования мышки и без возможности скорректировать введенную информацию.

Для внутренних программ под Windows похожая история: они все созданы без каких бы то ни было минимальных удобств для пользователя. Я лезу на стену и вою от ужаса, когда вижу системы, построенные на Clarion и Visual FoxPro. Их сразу можно распознать по уродским формам для ввода данных, которые предназначены для каких-то зомби с вывихнутым мозгом, но уж никак не для людей.

Еще один пример идиотской концепции интерфейса — все виденные мною системы разделения доступа во внутренних приложениях. Когда-то, в конце восьмидесятых — начале девяностых годов, в СНГ сложился стиль разработки ПО с расчленением приложения на задачи-оверлеи. Каждая такая «задача» запускалась в отдельном окне, в котором она принимала команды от пользователя, делала что-то с данными из локальной БД и клала их обратно. Разделение доступа заключалась в том, что создавалось огромное меню задач, и каждому пользователю давался доступ только на определенное их подмножество. Меню обычно хранилось в текстовом файле на каждом рабочем месте, и администратору безопасности, чтобы расширить/ограничить кому-то разрешения, приходилось оббегать все компьютеры, вручную внося исправления в эти текстовые файлы, «закомментировав» несколько строк. Защитить саму базу данных (будьте прокляты, тысячи dbf-ок!) не представлялось возможным, и она регулярно убивалась нечаянными действиями пользователей. Спасали только частые резервные копии. С тех пор в архитектуре внутреннего софта ничего не изменилось. Факт того, что сейчас рулят многозвенные клиент-серверы и веб-интерфейсы, разработчикам внутреннего ПО совершенно неизвестен.

3. Абсолютная негибкость конфигурации.

Очень мало или совсем нет параметров внутреннего софта, которые можно изменить для повышения удобства работы пользователя. У программиста почему-то никогда не возникает мысль, что условия на рабочих местах могут отличаться от того, на котором он пишет программу. Разрешение экрана — только 800х600, ни пикселя больше. Битов на пиксель — только 8, ведь 256 цветов — это очень даже много. Каталог, в который должна быть установлена программа — только «C:\ARM\», даже не обсуждается. Веселье начинается, когда две программы должны быть установлены в каталог C:\ARM\, потому что это очень популярное название. Экспорт данных — только на дискету под буквой «А:», пожалуйста, потому что выходное устройство намертво забито в исходном коде, а исходный код программист-пенсионер унес с собой в могилу. Я видел, как несчастные пользователи работали с такой программой, не вынимая дискету из дисковода, используя ее как промежуточный буфер между базой данных и сетевой папкой. Иногда после экспорта данных из приложения дискета не считывалась, поэтому приходилось ее форматировать и повторно запускать процесс экспорта с предварительной настройкой в течение получаса.

4. Невозможность понять, как это работает, без непосредственного общения с программистом.

Является как следствием трех предыдущих тезисов, так и следствием отсутствия вразумительной документации. Если документация и прилагается к программе, то она построена в стиле, который я называю «нате, отцепитесь», когда ее пишут только «для галочки» и не предполагают, что ее будет кто-то читать. По крайней мере, понять концепцию работы программы по ней можно очень редко. Поэтому прямая связь с разработчиком программы или с каким-нибудь опытным пользователей становится архиважной. Авторы ПО, обычно, очень не любят, когда им звонят и спрашивают, как пользоваться их программой, ведь для них все очевидно, и они не понимают, как можно быть таким тупым и этого не понимать. Следовательно, при каждой попытке заинтересованных пользователей разобраться происходят скандалы между отделами с последующим коллективным распитием валидола.

5. Невозможность самому разработать альтернативное, лучшее ПО.

Если вы — молодой энтузиаст и более-менее умеете программировать, то, когда вы будете ежедневно сталкиваться с кривым внутренним софтом, у вас обязательно возникнет идея переписать это уродство с нуля. Для типичного внутреннего ПО при хорошей университетской подготовке это займет у вас до одного-двух месяцев работы, и вы можете решить, что это замечательная альтернатива тому, чтобы мучаться с существующим ПО постоянно.

Однако, при попытке сделать это возникнут непредвиденные проблемы. Вы не сможете получить информацию, необходимую для безболезненного перехода всей организации на вашу программу (описания форматов данных, файлов экспорта/импорта для нормальной работы со смежными системами, полей любимых всеми dbf-файлов и др.), потому что никто из программистов ничего этого не документировал, а просто держал в голове. Если программист, создавший ПО, еще работает в организации, он вряд ли будет настроен на сотрудничество с вами, потому что вы автоматически станете его конкурентом в продвижении на следующую должность. Не у каждого энтузиаста хватит терпения докапываться с помощью дизассемблера до сути процессов, происходящих внутри.

К тому же, вы на всех уровнях организации будете встречать сопротивление вашим инновациям, потому что в любом коллективе есть пассивный балласт старых работников, которые изучили внутренний софт давным-давно, еще при старом программисте, написавшем его. Они не захотят переучиваться, даже если ваша программа в 100 раз лучше и надежнее, и это доказано тестированием.

Почему внутренний софт такой?

Причины, в общем-то, очевидны:

Программисты не заинтересованы в качестве своего продукта.

Большинство программистов в отделах автоматизации работают на фиксированной ставке со смехотворными премиями. У них нет никакого финансового стимула делать софт качественно. Если у программиста и есть внутренняя мотивация «сделать хорошо», то она существует недолго. Почему-то так получается, что чем больше организация, тем меньше каждый человек хочет для нее выкладываться.

Внутреннее ПО не разрабатывает молодежь.

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

Если внутреннее ПО заказывают на стороне, то на него тратят минимально возможные средства.

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

Вы можете спросить: «Автор, ты зачем все это рассказываешь? Мне вот все это было и так понятно, но я не думаю, что об этом стоит беспокоиться, ведь низкое качество внутреннего ПО — это вполне естественно, и тут ничего не поделаешь».

Я думаю, беспокоиться стоит. Плохой внутренний софт — это как айсберг, у которого самая опасная часть скрыта от наружного наблюдения. И когда ваша компания на него налетит, то вы даже не поймете, почему потонули.

Так зачем нужно улучшать внутреннее ПО?

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

1. Некачественный софт усиливает текучку кадров.

Когда у вас будет увольняться очередной работник, который, сидя за компьютером, постоянно нервничал и от злости иногда даже хлопал по монитору, потрудитесь спросить у него, что именно скрывается за формулировкой «по собственному желанию». Вполне возможно, что на 70—80% его недовольство рабочим местом было связано именно с плохо работающими программами. Пять особенностей внутреннего ПО, которые я описал выше, могут довести вполне спокойного человека до бешенства и нервного срыва, я сам это многократно видел воочию. А нервные срывы каждый день отнюдь не создают комфортных условий для работы.

2. Некачественный софт снижает эффективность работы сотрудников.

Если у вас в приемной выстраиваются длиннющие очереди клиентов к «девочке с компьютером», то это говорит об одном из двух: либо девочка — тормоз, либо тормозом является ее программа, которая не позволяет делать быстрый ввод данных (есть еще и третий вариант, когда тормозом являются и девочка, и ее программа, но мы его здесь рассматривать не будем). Хорошо спроектированный пользовательский интерфейс позволяет заводить информацию в систему на порядок быстрее, чем плохо спроектированный. Вывод: за одно и то же время можно обработать больше клиентов и получить с них больше денег.

3. Вы будете терять деньги из-за ошибок софта.

Когда слетает центральная база данных и работа всего предприятия приостанавливается на неопределенное время, вы теряете деньги. Когда ваш сайт взламывают малолетние хакеры-самоучки, и клиенты вместо коммерческого предложения видят чью-нибудь задницу на весь экран, вы теряете деньги и престиж. Если программа неправильно сводит баланс, или использует неточные формулы, это еще куда ни шло, вы даже можете не заметить потерь при большом денежном обороте. Хуже будет, если эти потери заметят ваши клиенты, которые мало того, что прекратят у вас обслуживаться, так еще и всем друзьям об этом расскажут.

Если какая-то программа является основой технологического процесса организации, то повышенные затраты на ее качественную разработку окупаются всегда. Понимание этого — одно из оснований коммерческого успеха и залог хорошего эмоционального микроклимата на рабочих местах.

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

Источник: http://shkuropiy.ru/