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

В мой первый же рабочий день я поняла всю систему работы компьютеров в нашей фирме. Админы закрыли доступ буквально ко всему.

Нет, вы не поняли.

Нельзя сменить обои.

Нельзя сменить цвет панели инструментов.

Нельзя убрать экранную заставку.

Нельзя изменить время отключения мониторов. Едва отвернулся — монитор уже выключен, и по экрану ползёт «трубопровод», одинаковый на всех компьютерах.

Невозможно самостоятельно убрать адресную строку из Проводника.

И самое главное — они внесли запрет на изменение настроек в Автокаде. Не хочешь смотреть в чёрный экран с белыми линиями, хочешь отключить сетку, изменить вид отображения веса линий или что-то наподобие? Хрен тебе: запрещено системой безопасности.

А дальше ещё интереснее. Наши админы, разумеется, собаку съели на работе в Автокаде, поэтому при звонке им с просьбой изменить что-либо в настройках ты слышишь отказ. Почему? Потому что им так удобнее. Потому что они-то знают, что на чёрном экране работать удобнее. Потому что им нравится, когда все веса линий отображаются одинаково. Потому что им нравится сетка.

Ребята, зачем бросаться из крайности в крайность? В чём-то я вас даже понимаю: проще поставить запрет на всё, чем потом бороться с вирусами и полетевшими программами. Но если вы заблокировали всё, что можно, зачем жалуетесь на тупых бухгалтеров, которые трезвонят вам каждые пять минут? Да по другому никак, без вашего администрирования компьютер и шагу не ступит!

Хотите жизни попроще — откройте хоть что-нибудь. Хотя бы возможность поменять обои. Хотя бы возможность сменить или отключить заставку. Смените приоритеты и разрешите менять настройки прикладных программ без вашего вмешательства. Автокад и 1С из-за изменения цвета фона не похерят компьютер. И будет всем праздник.

Никто не побежит переучивать старых сотрудников? Извините, но с таким отношением к IT-части вашего бизнеса вы довольно быстро пойдёте на дно. Надо идти и переучивать!

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

За полгода работы уговорил руководство на эксперимент: переписать интерфейс. Если получится — получал премию, нет — не получал зарплату. Терять было нечего, и с двумя авторами мы неделю ночевали в офисе. В итоге — ровно три дня на переучивание половины менеджеров. Через месяц на стол руководства лёг отчёт об увеличении продаж «переученных» на треть. Полчаса на донесение мысли, что если сотрудник настолько туп, что не смог постигнуть логичный и простой интерфейс, насколько же он тогда туп?

Много тут историй появилось про то, что софт неудобный. Некоторые пытаются привести аргументы, почему так вышло. Только это всё следствия. Как давно было сказано, рыба гниёт с головы. А в терминах разработки софта голова — это проджект-лид и архитектор. Только вот всё больше так называемых архитекторов, видимо, обучают на факультете «Возведение конструкций любой этажности из говна и веток». Многие не знают архитектуру проекта в целом. Большинство не знает и архитектуру отдельных блоков проекта. Это, по мнению многих «специалистов», waste.

Проджект-лиды озабочены выполнением процессов, скопированных у тех, кому методология помогла, зачастую без учёта собственной специфики и существующих процессов. Получасовые скрам-митинги из 15 человек, где каждый в красках описывает, как он ковырял в носу или выбирал себе цацки на Amazon. Проджект-лиды, заинтересованные только в том, чтобы таски в Jira были закрыты вовремя, без учёта качества работы. Что бы тест-кейсы были «зелёными» без учёта качества этих самых тестов. Юнит-тесты, состоящие из одной строчки «ОК».

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

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

Непрофессионалы — на всех уровнях этой грустной вавилонской башни. Дизайнеры интерфейсов либо не читали гайдлайны никогда, либо их знания поросли мхом и сожраны мозговыми слизнями. Видеть GUI, целиком состоящий из bad practices, — норма. Зато работа выполнена в срок. Код, целиком состоящий из гнилых костылей и копируемый из проекта в проект, поскольку «он же работает»; постановки задачи «сделайте, шоб работало, и хорошо!»; разработчики, даже примерно не представляющие себе предметной области, — это всё норма современного софт-девелопмента.

Но ведь у всех таски закрыты, тесты пройдены и баг-трекер чист. Никто не виноват, наверное.

Почему корпоративные системы часто выглядят просто ужасно? Разработчики ничего не понимают в интерфейсах? Всё очень просто.

Когда-то давно руководство заказывает разработку:

— Нам нужна программа, как в Экселе, только не в Экселе, а с кнопочкой «Сделать хорошо».

Разработчики делают, люди пользуются, но тут возникает новая задача:

— Нам нужно добавить сюда список контрагентов, чтобы видеть, кто что заказывал.

Разработчики делают, люди пользуются, но тут новая доработка:

— У нас у некоторых контрагентов особые условия, поэтому для них нужно добавить ещё 100500 полей и звонилочку.

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

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

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

Рано или поздно старая система становится настолько неудобной и непонятной, что её придётся менять полностью, но пока — терпите.

В крупной торговой сети с вилкой на логотипе и кроваво-красной расцветкой большинство рабочих процессов происходит в жёлтоподобной программной системе, написанной внутри. Низкое качество разработки для организации такого размера несколько удивляет. Система сложная, и некоторые ошибки в её работе неминуемы — это естественно. Однако эта система во многих местах пестрит грубыми нарушениями правил создания пользовательского интерфейса. А ведь хороший UI — залог быстрой и безошибочной работы сотрудников и, как следствие, радости клиентов. Хотя, возможно, я многого прошу. Пусть этот интерфейс хотя бы излечится от детсадовских проблем.

Неправильно расставленные tab orders, отличающиеся названия одних и тех же полей ввода в разных местах, дублирующиеся пункты меню и отсутствие их сортировки по алфавиту или какой-нибудь логике. Например, зачем нужны пункты «Реестр web заявок» и «Реестр web заявок (новый)»? А как насчёт «Сторнировать документ» и «Сторнировать документ (свой)»? Ещё интереснее — два пункта «Создание выезда» в одном меню, но с разными пиктограммами.

Система не запоминает ширину боковой панели. Переключает по Ctrl+Tab дочерние окна просто одно за другим, а не по последним активным. Поле ввода серийного номера не позволяет вводить маленькие буквы, заставляя нажимать Shift, хотя могло бы самостоятельно выполнять их преобразование.

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

Друзья разработчики! Я до последнего буду верить, что на самом деле вы хорошие, что вас просто заставили сделать всё в нереально сжатые сроки с невнятным ТЗ…

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

— Слушайте, друзья, помогите советом: как эту защёлку снять-то?

Ответ приходит незамедлительно:

— А тебе зачем?

— Ну дык неудобно же!

— У меня стоит. Мне очень удобно.

— Меня устраивала предыдущая дверца.

— А вдруг дети?

— У меня нет детей.

— Ну ладно, тогда можешь его открывать пинком сюда и рывком туда. Но вообще — ты неправ. Слушай, чувак, а зачем ты его вообще тогда повёз на профосмотр?

— Предложили — я и повёз.

— Ну, теперь ничего не поделаешь, только менять холодильник. Хотя я не понимаю, что тебя не устраивает.

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

Товарищи с форума техподдержки программного обеспечения, узнали себя?

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

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

— Демо-версия кончилась, надо сервак перезапустить.

Давным-давно, когда мы выводили из эксплуатации Пентиумы и вводили новые машины на базе Socket 478, в то время как электрики выводили из работы СМ-2М… Так вот, примерно тогда старшие товарищи в ответ на наши претензии нас учили.

Программист должен знать весь производственный цикл. Зачем? Да чтобы написать правильную, выверенную программу, которая у всех пользователей этого цикла будет работать. Разработчик должен посидеть за рабочим местом оператора в цеху, слазить на кран к терминалу, куда поставят его программу, везде поработать. Программа станет более человеческой, потому как её автор сам посмотрит на то, как она работает с точки зрения пользователя.

Ещё программист должен быть умным — умнее всех пользователей. Потому что он будет отвечать на вопросы пользователей, причём не по сути программы, а скорее про «почему не работает». Он должен уметь поставить себя на место любого пользователя и понять что же именно тот хотел.

Ещё программист-разработчик должен уметь вовремя устранять баги и обновлять свой продукт.

А ещё программист должен учить пользователей, чтобы они справлялись с большинством проблем сами. И молчать в тряпочку, дабы мало кто знал, что только он один знает весь жизненный цикл производства.

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

Секрет очень прост.

1. В качестве основного средства разработки используется старенький нетбук с экраном 10". Как вы понимаете, интерфейс должен быть понятным и лаконичным, иначе он просто не поместится на экране.

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

3. База данных лежит на тестовом сервере. Сервер тот находится на виртуалке в далекой стране, а канал к нему идёт через сотовый модем, поэтому обмен данными просто обязан быть эффективным.

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

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

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

Берём древний компьютер с процессором 80386 и сопроцессором. Запускаем любую программу, пробуем нажимать клавиши на клавиатуре. О чудо! Программное обеспечение откликается мгновенно, символы на мониторе (монохромном, кстати) появляются моментально.

У этого человека есть современный ноутбук с Виндоусом номер семь. Да, графический интерфейс, всё красиво, графика-круче-чем-Фаркрай. Понятно, что на обеспечение всей этой красоты уходят системные ресурсы. И лёгкие подтормаживания хоть и причиняют дискомфорт, но не убивают пользователя: он понимает причину тормозов.

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

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

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