Записки автоматизатора. Профессиональная исповедь

ГРАБЛИ КЛАССИЧЕСКИЕ 

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

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

— Это новый товар. Я его сначала завел по бумажной накладной в справочник номенклатуры, потом ввел саму накладную. А потом посмотрел на сам товар и понял, что это тефтели, а не котлеты, как написано в накладной.
— И как ты поступил?
— Исправил запись в справочнике номенклатуры. А в накладной все изменилось само.
— Кажется, я понял, — отвечаю я, подумав. — Смотри, — и набираю в строке поиска "котле". Экран прокручивается, и на нем подсвечивается строчка "Тефтели". За спиной раздается восхищенное "Ой", но я в это время уже представляю, что я сделаю с разработчиками в понедельник. Но воскресенье, предшествующее встрече, их спасает. Я не только никому ничего не пытаюсь оторвать, я даже могу разговаривать, используя только слова литературного русского языка:
— Вы что, название товара записываете на складской карточке?
— Мы только первые пять символов записываем, чтобы поиск шел быстрее.
Тут я становлюсь даже ласковым:
— А что вы делаете, если складские карточки уже созданы, а я наименование в номенклатурном справочнике поменяю?
— Кажется, ничего не делаем.
— То есть если я завел на склад "котлеты", а потом исправил в справочнике номенклатуры название на "тефтели", то что я увижу на карточке?
— "Тефтели". — А искать мне что нужно?
— "Котлеты"... Наверное, это не совсем правильно...
— Не совсем правильно?
— Согласен, это совсем неправильно. Мы к следующему обновлению переделаем...

Я начал именно с примера, чтобы не пугать читателя высоконаучными словами. Но в приведенном случае были нарушены принципы проектирования баз данных, описанные в классических работах 1970-х годов. Таблица базы "Складские карточки" не находится в третьей нормальной форме. Про это уже столько понаписано, что мне и добавить нечего. Появление новых СУБД и новых способов поддержания зависимостей в базе данных совершенно ничего не меняет: грабли продолжают работать даже при использовании триггеров и джобов (заданий, запускаемых автоматически в определенные моменты суток или через определенные временные интервалы).

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

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

Когда лень посчитать.

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

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

Феодальный документооборот.

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

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

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

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

Демократия в правах доступа.

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

В результате в системе доступа образуются зияющие дыры. Наиболее традиционная дыра состоит в предположении, что вновь заводимому в систему пользователю позволено все, пока ограничения доступа не будут прописаны в явном виде. То есть в системе "разрешено все, что не запрещено". Но использование этого демократического принципа по отношению к информационным системам категорически противопоказано.

При заведении нового пользователя в систему его права должны быть пусты. Только после задания роли у пользователя появляются права в соответствии с этой ролью.

Права, контрольные механизмы и прочие средства информационной безопасности (ИБ) — отдельная история при разработке и внедрении всех систем. Мало того что требования ИБ не принято закладывать при разработке систем (иначе откуда тогда столько систем, хранящих пароль на доступ к базе данных в виде незашифрованного текстового файла?), так даже и те средства, которые в системах все-таки реализованы, при внедрении систем не настраиваются почти никогда (наверное, на это уже не хватает сил после борьбы с функциональностью). Например, из десятка компаний, в которых мне пришлось побывать за год, на половине администраторскими правами в приложении были наделены все пользователи, и практически на всех пользователей в базе данных присутствовали учетные записи с паролями "по умолчанию". И если настраивать межсетевые экраны уже многие научились, то добыча любой информации изнутри локальной сети — до сих пор задача, с которой может справиться любой, кто умеет давить на кнопки.

При этом компании достаточно серьезно говорят о конфиденциальности... Вон она, эта конфиденциальность, — висит в открытом доступе. — Д. К.

Права по разным ролям у одного пользователя должны объединяться, а не интерферировать способом, неизвестным даже самому разработчику. А это тоже бывает достаточно часто.

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

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

ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ: ЧТО ТАКОЕ ХОРОШО

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

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

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

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

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

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

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

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

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

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

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

МОРАЛЬНЫЙ КОДЕКС НАЕМНОГО РАБОТНИКА

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

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

Моральный кодекс наемного работника

1.Я осознанно выбрал роль наемного работника, во всяком случае на этом этапе своей жизни.
2. Я сформулировал этот кодекс прежде всего для себя, так как он облегчает мне жизнь и упрощает мои взаимоотношения с работодателями.
3. Я применяю этот кодекс независимо от того, верят ли мне, что я его применяю.
4. Я не продаюсь в рабство, а поступаю на работу в фирму в соответствии с достигнутыми между мной и фирмой договоренностями, налагающими определенные обязательства как на меня, так и на нее.
5. Фирма, в которой я работаю, — мне дом родной. Пока я в ней работаю.
6. Я во всех случаях сохраняю к ней лояльность, отстаиваю ее интересы, не ворую, не беру взяток, откатов, подарков и не веду деятельности, которая может повлечь за собой ущемление ее интересов.
7. Вместе с тем даже в интересах фирмы я не пойду на нарушение моральных и этических норм, мною признаваемых.
8. Я работаю на фирму, а не на конкретное лицо в ней, независимо от ранга этого лица.
9. Я отделяю своих друзей и родственников от своих руководителей и подчиненных, даже если это одни и те же люди.
10. Я не работаю на другие фирмы, если это было оговорено при приеме на работу, но всегда сохраняю за собой право на свободную творческую деятельность, если обратное не было оговорено особо.
11. Коммерческие тайны, доверенные мне фирмой, я не разглашаю и после своего увольнения.
12. Я стараюсь повысить эффективность работы фирмы во всех случаях, когда могу это сделать, независимо от того, что написано в моей должностной инструкции. То, что поручено мне, я стараюсь сделать хорошо сам; в остальных случаях я даю рекомендации по улучшению работы тем руководителям, которые хотят меня выслушать. Если мои предложения не принимаются, я стараюсь оптимизировать работу в тех случаях и на тех участках, на которых могу.
13. Я всегда информирую руководство о реальном состоянии дел и реальных прогнозах, даже если руководство этого и не хочет.
14. Я соблюдаю дисциплину и субординацию, принятую в фирме.
15. Я никогда не пытаюсь доказывать свою правоту деструктивными способами типа "сделаю все в точности так, как ты сказал, а когда все рухнет, ты поймешь, кто был прав". 16. Если я не главный управляющий фирмы, я отдаю себе отчет в том, что, хотя успехи и неудачи фирмы до некоторой степени и зависят от моих усилий, но не в полной мере ими определяются.
17. Тезис "Проблемы фирмы — мои проблемы" я не принимаю абсолютно, но только вместе с тезисом "Мои проблемы — проблемы фирмы".
18. Я всегда стараюсь выполнить обязательства, данные мной при приеме на работу или в процессе работы, если фирма выполняет обязательства, данные мне.
19. Я по возможности не продолжаю трудовые отношения с фирмой, если, на мой взгляд, она реально не нуждается в моих услугах, даже если меня никто не гонит.
20. Я отдаю себе отчет и не скрываю от руководства фирмы, что эффективно могу работать в одном направлении не более лет пяти, после чего буду вынужден поменять сферу деятельности или фирму.
21. Я работаю в фирме на определенных условиях (оплата, режим работы и т. п.), оговоренных при приеме на работу или общепринятых, и в определенных условиях (помещение, климат, возможности питания). Если эти условия перестают выполняться или меня устраивать (по уровню ли зарплаты, количеству выделяемого мне на работе кислорода, состоянию физического или морального климата и даже собственного состояния), я могу покинуть фирму.
22. Я заранее предупреждаю руководство о своем желании покинуть фирму и, если руководство того хочет, обсуждаю с ним условия, при которых я останусь.
23. Если же руководство фирмы без предварительного уведомления снижает мою зарплату или резко ухудшает условия труда, я считаю себя вправе покинуть фирму также без предварительного уведомления.
24. Я никогда не шантажирую руководство угрозой своего увольнения.
25. Если я объявил о своем увольнении, то я увольняюсь, не обсуждая предложений, которые поступили после этого объявления.
26. Перед увольнением я стараюсь сдать дела своему преемнику, если могу его обнаружить, и делаю все возможное для того, чтобы мой уход не повлиял на состояние дел на фирме отрицательно.
27.. Однако, если при расставании часть моей работы останется неоплаченной, я считаю себя вправе не допустить использования результатов этой работы. Но без поджогов и диверсий.
28.Я никогда не делаю специальных гадостей фирме, в которой работал, после своего увольнения:
— не занимаюсь ее очернением;
— не переманиваю сотрудников только с целью их ухода из фирмы;
— не разглашаю ее коммерческих тайн;
— не нарушаю ее имущественных, авторских и других прав;
— не доношу и не навожу на нее; — не закладываю в компьютеры вирусы, не форматирую диски и не занимаюсь уничтожением или сокрытием информации любыми другими способами;
— не использую новое место работы для нанесения ущерба предыдущему.
29. Вместе с тем я не отношу к деятельности, перечисленной в предыдущем пункте, и потому оставляю за собой право:
— высказывать свое мнение о состоянии дел на оставленной фирме и характеризовать ее персонал;
— приглашать на работу сотрудников оставленной мною фирмы на новое место работы с предложением лучших условий работы или оплаты труда, если эти сотрудники мне действительно нужны: после увольнения я становлюсь для оставленной мной фирмы равноправным конкурентом на рынке рабочей силы.
30. Я стараюсь отказаться на новом месте работы от выполнения функций, которые вступают в противоречие с интересами оставленной фирмы, но, если это невозможно, действую в интересах своей новой фирмы. Потому что фирма, в которой я работаю, — мне дом родной. Пока я в ней работаю.

Разумеется, это мой кодекс. Перед тем как показывать его потенциальным работодателям, из него нужно вычеркнуть положения, которые вы не собираетесь выполнять. И последний совет этой главы (правило Галины Демич).

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