У нас есть система регистрации простоев оборудования. В ней рабочему нужно ввести комментарий о причине простоя вручную. А нам потом надо собирать статистику по этим данным для анализа, как работал цех и что приводило к простоям.
Рабочие вводят причины простоя разными словами, от души. «Шланг порвался», «они не успевают дать продукцию», «безобразно обрезана кромка» — это ещё цветочки. Одно только слово «железнодорожный» можно написать десятками способов — жд, Жд, ЖД, ж/д, ж\д, ж /д, ж д, Ж д, ЖД!!! — и так далее. С вывернутыми слешами, двойными пробелами и другими творческими формулировками.
В базе 13 миллионов записей, из них 700 тысяч уникальных, из которых остаётся примерно 500 тысяч после нормализации по регистру, слешам, пробелам и т. п. А нам нужно как-то разобраться, что не так и с кем.
Если вы сейчас думаете про ML, LLM и прочие модные слова, я вас огорчу. Оказалось, что есть простой кондовый способ, если применить немного ТРИЗа. В итоге получилось, что мы умудрились и рабочим сделать намного удобнее (что вообще-то редкость в реалиях производства), и дико помочь аналитикам.
Зачем нам знать причины простоев
Простои случаются всегда — либо нет заготовок (продукции), либо плановый или оперативный ремонт, либо тысяча других причин. Как выяснилось, пока элемент завода не становится бутылочным горлышком — причину простоев знать нам даже не надо. Они просто есть, они регистрируются, с этим можно жить. Условно, если бригада за смену делает 500 труб, а в суточном задании их 300 штук, простой на час вообще ничего не значит.
Когда же из-за простоя образуется бутылочное горлышко, это становится проблемой.
В этот момент (а лучше заранее, за год или полгода, чтобы простои не возникали) предполагается, что умные люди посмотрят все зарегистрированные причины и с ними разберутся. То есть нужен аналитический отчёт и какой-то дашборд.
Рабочие вводят причины вручную и творчески, двух одинаковых не найти. У рабочего порвался шланг — он выразил своё отношение к шлангу. Его подвёл коллега — он выразил своё отношение к коллеге. Формулировки крайне редко повторяются.
Анализ по-дедовски
Простои анализировали всегда, с момента появления системы. Результат выгружали в Excel, наши любимые естественные нейросети смотрели на эти комментарии и пытались сделать какие-то выводы. И какие-то точечные задачи решались, а системно порешать не получалось. Всегда втыкались, когда надо было очень резко узнать, как часто обрывался шланг, к примеру, на агрегате номер два. В верхнеуровневом классификаторе нет ни шланга, ни агрегата номер два, вся эта информация была в комментариях.
Вот тут-то начиналась настоящая боль аналитика. Ему надо было открыть эту портянку за два года по конкретному участку и, стирая скролл на колесе мышки до рези в глазах, проматывать все комментарии про этот участок и цех. Считать на палке, калькуляторе или как угодно ещё, сколько же раз там обрывался этот шланг. А комментарии все как есть разрозненные и нетиповые. Это больно.
Было много безуспешных попыток придумать классификатор комментариев. Каждый раз всё упиралось в потрясающее разнообразие жизни, успевать за которым не смогла бы даже сотня ответственных поддержаторов.
В какой-то момент аналитики, прослышав, что существует всеми любимый искусственный интеллект, решили воззвать к его силе в надежде, что взмахом волшебной палочки он разберётся.
ИИ нас всех спасёт?
Изначально предполагалось, что мы возьмём какой-нибудь NLP-движок, соберём причины в большую красивую таблицу и расклассифицируем по полочкам.
Ну то есть цех идёт к дата-сатанисту, тот что-то делает, всё получается, цех получает идеальный отчёт с весёлыми картинками. Все радуются. Кроме айтишников. Потому что работа эта — очень долгий подбор синонимов, специфичных для каждого цеха, сведение кучи лингвистических гнёзд, работа с аббревиатурами и глубокое вникание в специфику цеха. Попросту — очень долгая тупая повторяющаяся работа. И очень дорогая.
Мы попытались перекинуть мячик обратно и предположили, что можно сделать какую-то простую среду для аналитиков, работающих внутри функциональных блоков цеха. Оказалось, что они даже знают азы Python и в принципе могут освоить работу с его лингвистическими библиотеками. Получилось даже обучить несколько человек.
Они решили свою задачу прямо на курсах и скрылись в закат. Больше мы их не видели. В следующем году пришли новые аналитики, которые ничего не знали.
Дата-сайентисты плакали и страдали.
Рабочие вводили в комментарии про причины простоя свои творческие формулировки как умели, от души, соревнуясь кто в литературности, кто в краткости, кто в аббревиатурах.
Жизнь продолжалась.
ТРИЗ-подход
Мы решили подойти по-тризовски и задали себе вопрос — как бы сделать так, чтобы комментарии стандартизовали сами себя? И подумали — а что если дать рабочим не вводить творчески-неповторимые формулировки, а сгруппировать все комментарии в базе один раз и давать выбрать причину простоя?
Так! Где-то уже это было! Идея с классификаторами уже не раз проваливалась. Что в ней было не так — классификатор кто-то должен поддерживать и актуализировать. Это нам не годится.
Значит, надо, чтобы комментарии ещё и писали сами себя! При этом ещё и самоунифицировались.
И мы решили поэкспериментировать с подсказками и сыграть на лени.
Прямо на стадии прототипа мы наткнулись на одну суперидею — сделать так же, как в поисковой строке браузера. Ну или там Яндекса. У них функционал похож на браузерный )
Опять же, если вы думаете, что мы нашли LLM и всё такое — сообщу что нет.
Короче, Elastic без LLM-наворотов. Просто очищена исходная база, английские «c» сведены к русским «с», слеши в одну сторону, строки подрезаны по пробелам и так далее, регистр не играет значения.
Получилось вот что:
В чём прикол
Ну сделали поисковик по вычищенной базе комментариев и что здесь такого? Прикол в том, что у нас есть вес показа подсказки:
- Частота ввода — чем чаще подсказка использовалась, тем она выше.
- В зависимости от места ввода. Каждый терминал расположен на определённом месте, мы это место знаем, и знаем, что в архитектуре цеха к нему близко. То есть нас интересует не просто частотность строки в базе — мы ещё даём дополнительный вес за то, что она вводилась с этого места или рядом. То есть характерные для места причины всплывают выше.
- Свежесть. Если такой комментарий использовался недавно, есть шанс, что он понадобится снова — он всплывает выше. Дремучие комментарии 2010-х годов, соответственно, спускаются ниже, а их там довольно много.
Система работает просто, как колесо!
Пользователи прониклись. Набирают три буквы, смотрят в экран, клацают. Очень радуются, что не надо нажимать много кнопок. И у нас получился тотальный win-win со всех сторон. Рабочим не надо писать много букв. У аналитиков начали выпрямляться отчёты. У айтишников не сильно прибавилось головной боли, потому что сделано просто и без геморроя с нейросетями.
В общем, мы сыграли на человеческой лени. Гипотеза в том, что за следующие два года (да, да, у нас не розовые очки) рабочие естественным путём снизят количество используемых причин до более-менее реальных и у них всегда наверху будет релевантное. Соответственно, для того, чтобы строить красивые картинки и дашборды, не надо будет очищать данные и пытаться понять, как конкретно эти краны называются в этом цехе и почему в зависимости от цеха одна и та же аббревиатура может значить 5 разных вещей. Методологи автоматизированно определяют уже давно, как это влияет на производительность цеха, там развитый аппарат. Им нужны только чистые данные, и они будут.
100 мс
Чтобы это работало, нужно соблюсти условие показа подсказки за 100 мс. Мы с UX-специалистом посчитали, сколько пользователь готов ждать, чтобы не вводить творческие комментарии. Получилось, что граница где-то в районе 400 мс. Терпение у пользователей далеко не бесконечное. В ТЗ записали 100, потому что кто будет ждать больше 100 мс? И вот Elastic (точнее OpenSearch), правильно сделанный индекс с учётом весов и обычный запрос без нечёткого поиска.
Просто, дёшево, сердито, быстро.
Итог
Система несколько месяцев в эксплуатации.
Измеряем три метрики:
- Долю ответов внутри 100 мс (всё в порядке).
- Количество уникальных комментариев в неделю (сколько не воспользовались подсказкой).
- Долю уникальных комментариев в неделю.
За эти недели выяснилось, что, оказывается, за 14-то лет многое уже случалось (почти всё) и, просто назвав одно слово из проблемы, можно получить целый длинный комментарий.
Мы понимаем, что многие ситуации повторяются реже месяца: импидоры каждый день не меняют. Через два года посмотрим, но впечатления пока очень хорошие.
Бэклог на улучшение у нас есть, но пока он пылится на столе — поскольку всё работает достаточно неплохо. Мы решили зря не тратить ресурсы в улучшайзинг и подождать хотя бы сколько-то времени, полгодика до первых результатов.
Ну и ещё у нас есть потрясающий случай, который показал, как быстро люди привыкают к хорошему.
Дело в том, что во время бета-тестов у нас упал деплой из-за блокировки докерхаба, а резерв прикрутить мы не сразу успели. Так вот, рабочим уже понравилось вводить всё по подсказкам — а тут пришлось снова вручную. И они пришли в конце смены к нам поговорить:
— Мужики, а когда подсказки-то заработают? Поломались!
— Когда исправите? Ничего нормально сделать не можете!
В общем, настолько сильной поддержки пользователей у нас давно не было. Мы счастливы.
Комментарии (48)
fizikdaos
21.11.2024 11:44Как-то не бережливо. Куча работы: заставляете рабочих отчеты писать, их хранить надо, анализ данных делать. И ноль реакции на отчёты. А все это на случай "вдруг кому-то захочется на них посмотреть".
Radisto
21.11.2024 11:44Честно говоря, в промышленности полно не просто специалистов, а целых отделов, которые заняты именно этим: пишут отчёты, которые вдруг кому-то будут нужны. Более того, многие эти люди будут сильно нервничать, если узнают, что их отчёты действительно кто-то будет смотреть - это означает, что возможно что-то произошло, причем не сильно хорошее. То, что люди пишут эти отчёты, для них вовсе не что-то новое наверняка. Раньше они вероятно делали то же самое в бумажном виде и тратили намного больше времени намного более бесцельно
NikolayProklov Автор
21.11.2024 11:44Вообще-то не ноль.
Во-первых, данные о простоях регулярно используются, и рабочие это видят. Анализ проводится не только стратегически раз в полгода-год, но и ежемесячно: одни сотрудники вводят данные, другие их обрабатывают.
Во-вторых, точность анализа помогает выявить частые поломки, причины, оптимизировать закупки комплектующих и снизить издержки. Чем чище данные, тем лучше результат.
Moog_Prodigy
21.11.2024 11:44Данные о простоях используются в основном при расчете КТУ, где эта система внедрена. А на подобных предприятиях она много где. И да, рабочие это видят! Когда получают 2/3 от номинальной ЗП, и это еще не самый тяжелый случай. А то, что каждую неделю рвется шланг на агрегате №8 - ну на то и обслуживающий персонал, мы им километр шланга купили, пусть меняют, так дешевле.
Никогда не встречал, чтобы данные о простоях, собранные автоматической системой, как то влияла на начальство, систему снабжения и управления. Заявки все равно вручную заполнять, и ее еще надо "защитить", потому что "у завода нет столько денег", пока на пальцах не распишешь, что если они не купят частотник в запас, то простой им выйдет в месяц. Вот это уже аргументы, и программа их привести не сможет, хоть как подробно ни расписывай. Электронные заявки и комментарии - дополнительный плюс к "защите" заявки, но туда никто не смотрит - страшно. Это универсальное правило, действующее от мелких ИП до крупных концернов. Где не так - ну то значит эффективные совы недоглядели, есть еще куда оптимизировать.
redfox0
21.11.2024 11:44О, частотник... Как-то поставили норию (для засыпания зерна в хранилище), так нужно было обеспечить нужную производительность. Закупили ковшички нужных размеров, так неделю эти ковшички монтируют, неделю грузят зерно, потом опять монтируют уже другие.
Выбили закупку частотника, смонтировали. Показали начальству, одобрило. Приезжает через некоторое время "А куда делись 20 тонн зерна?!" "Так усё погрузили начальникама".
fizikdaos
21.11.2024 11:44Я пытался в игру слов. Не бережливо - не соответствует принципам бережливого производства. По ним любые простои надо устранять. Вы скажете что их слишком много и это невозможно? Нет, после устранения основных причин поток жалоб сильно сократится, и можно реально на каждую жалобу реагировать.
Шланг порвался. Может купленные шланги бракованные и надо все разом менять? Или плановое тех.обслуживание станка забыли сделать? Лучше бы это расследовать и принять меры сразу, а не ждать когда это на статистике через полгода проявится.
Moog_Prodigy
21.11.2024 11:44С точки зрения производственника, который этих шлангов навидался, то есть меня:
Нет, купленные шланги не бракованные. Просто они рассчитаны на давление 300 Атм. И хорошо бы все, вот только термопласт-автомат при закрытии формы, а точнее при ее трогании, развивает давление в этом шланге порядка 1000 атм. Импульсно, поэтому проблема не проявляется сразу. Шланги на 1000 атм стоят уже "дорого", поэтому купим километр шланга на 300 атм согласно документации термопласт-автомата (это еще хороший вариант). Есть и другие приколы. Шланг и его резина рассчитан под спирт, а через него гонят масло...Шланги в порядке, а на масле сэкономили, или наоборот - распилили миллионы, купили масло но оно ест шланги. Масло дорогущее! Значит шланги виноваты! Или обслуга. Ну если шлангов запасти километр, то с обслуги надо наоборот, списывать.
fizikdaos
21.11.2024 11:44Я как бережливец со стажем, этих отмазок наслушался достаточно. Конечно всегда есть причины почему оно так, и свалить вину на кого угодно можно, это дело не хитрое. Только пользы от этого нет. Шланги нормальные, но выходят из строя? Считайте расходником, делайте ТО и меняйте заранее. Не хотите менять постоянно? Ок, сделайте запасных, положите возле станка, поставьте быстро разъемные соединения, еще что-то как-то чтобы ремонтировать можно было за 5 минут.
Moog_Prodigy
21.11.2024 11:44Проблема в том, что никто не хочет брать на себя ответственность. И даже те же самые слесаря, вместо того, чтобы пару дней почесать репу и поставить быстросьемы (заказать, изготовить самим) как показывает опыт, не будут этого делать. Вот они будут мудохаться с заменой шлангов каждый месяц, закупать побольше хомутов и прочего, но переделать - "а нафига нам это надо? Нам за это не платят!". Их начальник мог бы принять такое решение - но это значит расходы, а любые расходы требуют обоснования. Если он пойдет к вышестоящему, и скажет "Мои рабочие заколебались эти шланги менять, давайте переделаем, купим то-то и то-то" то его пошлют. Вот если бы он сказал "простой линии пока они меняют шланги - 10 миллионов рублей в час" - вот это действует на вышестоящих отрезвляюще. Правда есть одно маленькое "но". Большинство высоких начальников стремятся экономить копейку, теряя рубль. Боязнь ответственности, некомпетентность - вот это и оно. А начиналось то все с простых шлангов. Пока наверху порядка нет, и внизу не будет. То же самое и с вашим "бережливым", когда вместо нахождения вот таких вот узких мест на производстве эти берегини придираются к ровности линий на полу, и чтобы инструменты были разложены в алфавитном порядке.
keemailme
21.11.2024 11:44лучше дать ввести потом предлагать а то это наопережение не только сбивает да меняет смысл но так-же заставляет забыть свой более точный вариант даже в опечатке - потом турбины на гэс взрываются: а ведь он хотел предупредить
Nikola_Piterskiy
21.11.2024 11:44Ниже есть коммент про лень, согласен я полностью тут. Все эти подсказки они конечно облегчают жизнь и порой ты даже не хочешь писать например в поисковике и идешь и прям пытаешься найти в списке то что тебе нужно. К сожалению это точно никак не развивает нейронные связи и в целом снижает общий уровень интеллекта людей на земле...
CitizenOfDreams
21.11.2024 11:44Да, и почему он выдает подсказки из середины слова? Слово "импидор", извините мой французский, вменяемый человек начнет печатать с "имп...", а не с "пид..."
NikolayProklov Автор
21.11.2024 11:44В данной задаче не подходит вариант с привычным "Т9", когда идет автозаполнение каждой последующей буквы. Здесь нужно угадать целую формулировку, в которой первое напечатанное слово не обязательно должно стоять в начале предложения.
skssxf
21.11.2024 11:44В списке подсказок все фразы, содержащие поисковую подстроку в начале слова выводятся раньше, чем те, где она в середине слова?
NikolayProklov Автор
21.11.2024 11:44Не всегда. Все зависит от того какой рейтинг у данной строчки. В статье про это подробно рассказано, что для расчета порядка очередности подсказок мы используем коэффициент, которые присваиваются исходя из количества использования, конкретного места ввода данных и актуальности по новизне.
Squoworode
21.11.2024 11:44Всегда найдётся человек, который засомневается, как пишется это слово: импидор или энпидор, и попробует найти по однозначно определяемым буквам...
Ndochp
21.11.2024 11:44А при частой причине - еще и попробует найти волшебные 3 буквы, которые принесут нужную подсказку наверх.
ImagineTables
21.11.2024 11:44Крутяк. Я когда-то решал похожую задачу, но ещё надо было 1) предложить юзеру варианты, которые вводили другие юзеры, не нарушая приватность, и 2) предложить хоть что-то, когда юзер ничего ранее не вводил вообще. Тогда я взял поисковик второго эшелона (он давал 500 бесплатных запросов на один айпишник в сутки), и стал подмешивать его подсказки к выдаче.
muxa_ru
21.11.2024 11:44Рабочие вводят причины вручную и творчески, двух одинаковых не найти. У рабочего порвался шланг — он выразил своё отношение к шлангу. Его подвёл коллега — он выразил своё отношение к коллеге. Формулировки крайне редко повторяются.
И для того, чтобы облегчить работу аналитиков, вы решили избавиться от дополнительной информации о проблеме, сведя всё к конечному списку популярных вариантов?
NikolayProklov Автор
21.11.2024 11:44Не совсем так. Мы убрали самую грязную и муторную работу с аналитика, а именно анализировать одинаковые причины простоя без ручного сведения их к единому написанию.
uuger
21.11.2024 11:44Пилил я как-то дашборд по "внутренней" системе автоматизированного перевода... Так вот, при составлении глоссария наиболее часто переводимых словоформ выяснилось, что дяди и тёти в дорогих костюмах и в бизнес-центре класса "А+++" очень быстро кинулись проверять, насколько хорошо система переводит более классические слова из трёх (и более) букв.
alan008
21.11.2024 11:44Дам еще подсказку, как повысить удобство такого фильтра. Можно бить исходные строки на слова и позволять вводить фильтр по совпадению начала каждого введенного слова с одним из слов в исходной строке (можно даже вообще без соблюдения порядка слов, но это дело вкуса)
Например, если в поиске введено
"пер сты"
то найдёт фразы
переделать стык
переделать сварной стык
и (если делать без учета порядка слов)
стык переделать
стык сварной переделать
Сначала такая фильтрация кажется странной, но она позволяет по первым буквам части слов длинной фразы очень быстро находить такие фразы. В нашей системе такой поиск используется. При этом фильтр с учетом деления на слова считается просто динамически, в момент применения фильтра (т.е. разделенные слова мы не храним, а каждый раз просто "пересчитываем" удовлетворяет ли каждая фраза фильтру, это довольно быстро если фраз меньше 10 тысяч и если они не слишком длинные).
adeshere
21.11.2024 11:44Как пользователь, могу только позавидовать вашим клиентам. Мне по долгу службы приходится пользоваться одной "Интеллектуальной системой...", которой ее создатели очень гордятся. У нее уже есть десятки тысяч вынужденных пользователей, насколько я знаю. Несколько лет назад я ввязался в смертельный бой со службой поддержки этой ИС (который, разумеется, проиграл). Но один эпизод этого боя настолько попадает в тему этой статьи, что мне захотелось про него рассказать. Речь про интерфейс ввода данных - а именно, выпадающий список
Дело в том, что 90% работы юзера в этой ИС - это ввод туда "личных данных"
Я даже не буду тут говорить, что почти все эти данные уже есть в другой общедоступной системе
гораздо менее глючной. Причем туда они загружаются полуавтоматически, без усилий со стороны юзеров. Но импортировать эти данные в ИС почему-то нельзя. Ни автоматически (они там между собой оргвопросы не порешали), ни вручную (если я выгружу свои личные данные из второй системы в стандартном текстовом виде, то корректно загрузить их в себя "Интеллектуальная система..." почему-то не может. Наверно, не любит делать "тупую работу", она ж интеллектуальная? ;-).
Ну да ладно, не буду уходить далеко от темы статьи
Так вот, совершенно типичное действие пользователя "Интеллектуальной системы..." - это выбор страны. Учитывая, что 90% пользователей там из РФ, и что в 80% случаев надо выбрать Россию, то было бы логично ожидать, что в выпадающем списке РФ будет на первом месте, да? А вот и не угадали! В выпадающем списке страны перечислены в алфавитном порядке! Причем окошко прокрутки даже на моем огромном экране минимальное - около 10 строчек. Надо бросать клаву (я же занимаюсь вводом, т.е. преимущественно набираю или копирую текст), брать мышку, и листать, листать, листать....
Впрочем, создатели списка все-таки не совсем идиоты. Они (ура!) оставили мне возможность сначала щелкнуть мышкой по кнопке раскрытия списка, а затем вновь взять в руки клавиатуру и ввести первую букву! Ура!!! Я нажимаю "R" и сразу вижу список стран на R! Но где же РФ? А, она опять не поместилась в окошке... Неужели надо снова брать мышку и листать? Но нет, я ж умный! А попробую-ка я ввести Ru (в руках-то уже снова клавиатура). Теперь-то я попаду куда надо, верно? А вот и нет! Снова не угадали! Теперь у меня в окошке список стран не на "Ru", а на "U"!
Если быть честным
то при очень быстром наборе "Ru" список все-таки воспринимает вторую букву, как буквосочетание, и работает правильно. Проблема, однако, в том, что в период активного ввода данных основной массой пользователей (это конец февраля-март) сервер "Интеллектуальной системы..." всегда перегружен, и система постоянно "полуподвисшая", так что тайм-аут почти всегда превышается, и буква "U" интерпретируется, как начало нового слова.
Я бы не стал тут все это писать, если бы баг со списком был бы единственным
Чего стоит хотя бы требование ее авторов к юзерам никогда не ошибаться при вводе, набирая многие тысячи символов в интерфейсе, который буквально принуждает к ошибкам. А поскольку внутренняя БД организована там довольно сложно, однажды введенная ошибка при каждом следующем пополнении базы мультиплицируется, отображаясь из одной таблицы в другую. Там появляются некорректные записи-дубликаты. Но самый главный прикол в том, что эта вторая таблица также отображается на первую, поэтому каждый дубликат во второй таблице при следующем пополнении базы рождает несколько новых ошибок в первой таблице. И так по кругу. При этом инструменты по исправлению этих ошибок либо глючат, либо требуют административных прав доступа. А наиболее доступный для обычного юзера протокол - это:
1) Удалить из базы все свои глючные данные (которые он, возможно, вводил часами). Фича в том, что к каждому элементу базы данных обычно привязано несколько юзеров, поэтому при такой операции их данные тоже будут удалены
2) Самостоятельно договориться с другими юзерами, которых косвенно затронула эта ошибка, чтобы они самостоятельно удалили из базы введенный ИМИ контент, который был затронут исходной ошибкой в ходе ее мультипликации
3) После этого - заново ввести в базу все удаленные данные всем участвующим в процессе юзерам. Причем НЕ ОШИБАЯСЬ!
Мы писали в поддержку этой "Интеллектуальной системы..." талмуды на много-много страниц. Изредка (далеко не всегда!) оттуда приходили ответы. Как вы думаете, с каким содержанием? А вот и снова не угадали! Основной смысл этих ответов сводился к двум пунктам:
1) а чего Вы хотели? Система ж бесплатная. Так что пользуйтесь, чем дают.
2) Ну а что касается всяких неудобств и ошибок - так это ж вы сами себе злобные буратины! Ибо начали работать с системой, не прочитав справку! Хотя там на первой странице написано: "Прочтите СНАЧАЛА справку!!!". В которой, в свою очередь, черным-по-русскому сказано: "ОШИБАТЬСЯ при работе с системой НЕЛЬЗЯ!!!"
В общем, надежду достучаться до руководства мы давно потеряли. Это все равно, что писать в пустоту. Да и отдельные костыли в ней (для наиболее массовых багов)
иногда все-таки появляются
Но с таким скрипом, что у меня возникает впечатление о неустранимых архитектурных проблемах. Что исходная архитектура просто не была приспособлена к масштабированию. Представьте себе, что Вы сделали систему для учета своих личных домашних вещей. Строго в кругу семьи. И завели в базу "шкаф в комнате", "полка на кухне", "тумбочка в ванной". Для одной квартиры этого описания хватит. А потом Ваша система понравилась руководству, и ее решили внедрять по всей стране сразу. И в базе появились тысячи одинаковых "шкафов в комнате". А еще там лежат "красные полотенца". Которые должны быть привязаны к конкретному шкафу. Только вот совершенно одинаковых шкафов в системе теперь полно, и к какому из них привяжется Ваше "красное полотенце" в процессе ввода - одному богу известно. В результате Ваше полотенце привязывается к шкафу в другой стране. А потом приходит Ваша жена, ей надо в душ, а в Вашем шкафу все еще нет полотенца. Естественно, она вводит его в систему повторно. После чего у лично вашего полотенца появляются точные дубликаты (наряду с почти неотличимыми в интерфейсе системы аналогичными полотенцами от других хозяев)..
Наутро в систему входит Ваш сын, чтобы ввести туда "одеяло". Он гораздо умнее, он хочет убедиться, что привязывает его именно к нужному шкафу. Да и авторы системы не дураки - теперь при вводе данных можно проверить - а что уже лежит в этом шкафу? Поэтому он выбирает из всех доступных шкафов именно тот, где лежит то самое "красное полотенце". Ну и какой вероятностью это будет Ваш шкаф, а не какой-то другой, если совершенно одинаковых полотенец в системе уже штук пять?
В общем, смысл это сообщения сводится к трем основным тезисам:
1) Не каждое восхитительно работающее в камерных условиях приложение можно масштабировать на всю страну без проблем. Иногда для этого лучше сразу переписать ядро и переиначить структуру баз. Но вот что делать, если начальство этого не понимает, и не закладывает соответствующие бюджеты - это вопрос...
2) Если автор однопользовательского приложения, с которым он работает сам, заложил в интерфейс принцип "не ошибайся", то это его проблемы. Но когда основанное на этом принципе приложение масштабируется на многие тысячи юзеров - то это свинство и профнепригодность.
3) А также у меня есть слабая надежда, что у кого-то из присутствующих здесь разработчиков "Интеллектуальной системы..." (уверен, они сразу поймут, о чем речь) наконец проснется профессиональная гордость. И что он начнет более ответственно относиться не столько к своему коду (вполне возможно, что этот код неплохо написан и идеально отвечает ТЗ), но и к тем принципам и задачам, на которые опираются эти ТЗ. И попытается все-таки как-то на своем уровне что-то объяснить руководству. Потому что со стороны вынужденных клиентов достучаться до него невозможно.
P.S. И чтобы не быть совсем уж жалобщиком-попрошайкой
добавлю
что в 2020-21гг я составил баг-репорт в нескольких частях по наиболее злободневным проблемам юзеров этой "Интеллектуальной системы..." (так получилось, что мне тогда приходилось помогать многим коллегами при работе с ИС, и я раз за разом упирался в одни и те же грабли, что и послужило поводом для формализации баг-репорта).
Весной 2023г, когда нам в очередной раз пришлось пополнять базу данных "ИС", основная масса из этих проблем еще не была решена. И принципы разговора с юзерами тоже не поменялись. Увы.
Но! Если вдруг разработчики "Интеллектуальной системы..." поменяют свою позицию, и выразят желание всерьез рассматривать такие баг-репорты (и даже что-нибудь исправлять), то я готов заново перетестировать все замеченные мной баги и подготовить отчет, актуальный на сегодняшний день.
andreishe
21.11.2024 11:44я ввязался в смертельный бой со службой поддержки этой ИС (который, разумеется, проиграл)
Мам, я разговариваю с мертвецом!
voldemar_d
21.11.2024 11:44Не знаю, о какой системе идет речь, вспомнил про сайт РЖД, а именно систему покупки билетов.
Прикол в том, что ее поведение разное в веб-версии и приложении. Казалось бы, зачем внутри использовать два разных движка?
Отдельная история - с ограничениями на покупку билетов. Которые динамически меняются, зависят от каких-то сезонных акций и ретроградного Меркурия. Но выглядит это обычно так: при невозможности продать билеты (а мне, соответственно - купить) система просто выкидывает на какой-то стартовый экран. Без каких-либо объяснений, сообщений об ошибках и т.д.
Отчаявшись, мы решили попробовать купить билеты в приложении, и, о чудо - оно сумело выдать явную причину вроде "не разрешается одновременно покупать столько-то билетов при таких условиях". Почему сайт это же не может выдать?
Еще я слышал, что на сервисах вроде туту.ру этих же ограничений нет, и сайтом пользоваться проще и удобнее.
vikarti
21.11.2024 11:44Я вот вспоминаю то приложение над которым мы работаем. Клиентов много, очень.
Традиция что если приложение не получает ожидаемый ответ - клиенту показываем сообщение вида "упс что-то пошло не так, наверно у вас VPN". Даже если само приложение - знает, даже если от бэка пришел (и был записан в лог) статус-код по которому можно бы понять, даже если от бэка пришел ответ на русском языке (ну да - там тексты видимо понятные среднему пользователю хабра но совсем не факт что понятные среднему пользователю пикабу) что не так (и был записан в лог).
voldemar_d
21.11.2024 11:44Так пусть бы хоть что-то написало. А то просто молча либо никак не реагирует на нажатие кнопки "Далее", либо выкидывает на стартовый экран, также молча. Пусть бы даже какое-то невнятное сообщение было - "operation timed out", "нет связи с базой данных" или "невозможно завершить операцию". Это хотя бы как-то могло навести на мысль о причине проблемы. А так можно хоть зазвониться в горячую линию РЖД, там наверняка будет сидеть ничего не знающий оператор, который ответит что-нибудь в духе "Попробуйте еще раз позже".
MaFrance351
21.11.2024 11:44Одно только слово «железнодорожный» можно написать десятками способов — жд, Жд, ЖД, ж/д, ж\д, ж /д, ж д, Ж д, ЖД!!! — и так далее. С вывернутыми слешами, двойными пробелами и другими творческими формулировками.
И это ещё без учёта опечаток или ошибок. Когда вбивают "второпласт" или "фтулка", то никакая нормализация по регистру и числу спецсимволов в нормальный вид это не приведёт.
VGoudkov
21.11.2024 11:44Не будьте столь категоричны. Есть метод триграмм, есть фонетические алгоритмы
CitizenOfDreams
21.11.2024 11:44Есть метод триграмм, есть фонетические алгоритмы
Это все тонкий баланс между "не найти слово с опечаткой" и "найти кучу посторонних слов, потому что алгоритму приглючилось, что они похожи на нужное". Второе обычно бесит сильнее, так что лично мне хотелось бы, чтобы поисковые алгоритмы давали больший приоритет тому, что ввел пользователь, а не тому, что они сами нафантазировали.
voldemar_d
21.11.2024 11:44В общем, мы сыграли на человеческой лени. Гипотеза в том, что за следующие два года (да, да, у нас не розовые очки) рабочие естественным путём снизят количество используемых причин до более-менее реальных и у них всегда наверху будет релевантное.
Не боитесь, что лень выйдет на следующий уровень, и рабочие начнут просто не задумываясь выбирать первый вариант? Он же самый частый - значит, вероятность его повторения самая высокая - ну так и вероятность выбрать не то минимальная, и зачем задумываться? Пусть начальство думает, нет?
NikolayProklov Автор
21.11.2024 11:44В нашей компании развитие производственной культуры стоит в топе задач и она сейчас на высочайшем уровне. Сотрудники понимают какая ответственность стоит перед ними и какая работа происходит после того, когда он ввел данные. Можно и без «подсказчика» написать всё что угодно, если ты не вовлечен в процесс. Вот вы например забивая в поисковике нужные слова и видя, что первая строчка вам не подходит, все равно используете её?
voldemar_d
21.11.2024 11:44Поисковик в сети - плохой пример. Всегда ли легко понять, что первая строчка не подходит? Может, как раз подходит?
Я искренне рад, если все ваши сотрудники хорошо понимают, какая на них ответственность, и что происходит после того, как они вводят данные. Но, все-таки, полностью ли здесь исключена вероятность ошибки? Человека может что-то отвлечь, он может быть не в духе, не очень хорошо себя чувствовать и т.д. Он может быть новичком, в конце концов. Имхо, здесь бы еще добавить обязательное подтверждение выбранного варианта другим сотрудником (более опытным, начальником, например).
Можно и без «подсказчика» написать всё что угодно
Можно, но в статье же как раз описаны недостатки такого подхода.
orefkov
21.11.2024 11:44Делал подобный подбор товаров и контрагентов в 1С году так в 2003-2004. Штатными средствами 1С работало чудовищно долго, к дбф версии прикрутил фокспрошный драйвер через ADO. Скульщикам было проще, они сразу могли прямой запрос сделать. Потом и для дбф сделал прямые запросы через 1sqlite.
redfox0
21.11.2024 11:44Делали как-то автодополнение фамилий, имён и отчеств. Бралось просто из справочников (но справочники иногда дополняются вручную). Из особенностей - фильтр по полу, то есть для женского пола показывались только женские имена, для мужских - мужские.
9w846hr978w
21.11.2024 11:44Прежде, чем так напрягаться и привлекать тяжелую артиллерию, можно было обратиться к опыту четверть вековой давности - открыть абсолютно любую программу для ведения медицинских карточек, а именно процесс сбора анамнеза и вы бы увидели решение своей проблемы.
redfox0
21.11.2024 11:44Кстати, этим вы напомнили мне экспертные системы. Не знаю, насколько здесь применимо и как стабильно работало бы.
voldemar_d
21.11.2024 11:44открыть абсолютно любую программу для ведения медицинских карточек, а именно процесс сбора анамнеза
Слышал, как в одной поликлинике пытались пробиться через такую систему. В какой-то момент в выпадающем списке просто не оказалось нужного варианта, а пока вариант не выберешь, не даёт дальше пройти, и вбить свой вариант нельзя. А если выберешь что-то неподходящее, там дальше какие-то еще более неподходящие варианты действий были доступны вроде записи не к тому врачу, который нужен.
SeregaSA73
21.11.2024 11:44Для информации, очень неудобно когда список вариантов не влезает в экран и приходится листать, да варианты которые не относятся к работе, да и дубликаты ответов (изменена одна буква) тоже как то странно выглядит и занимают полезное место.
voldemar_d
21.11.2024 11:44Не знаю, сталкивались ли с программой "Навигатор образования" для школ. Сейчас, чтобы даже в бесплатный школьный кружок ребенка отдать, необходимо обязательно записаться через эту систему. Это тихий ужас. Огромные выпадающие списки на 100500 вариантов, среди которых нужно найти нужный среди неочевидных названий, и приходится гадать, то ты выбрал или нет. Поиск по названию курса/кружка не работает, хотя поле для поискового запроса есть.
AndreyYu
21.11.2024 11:44Рабочие вводят причины простоя разными словами, от души. «Шланг порвался»,
Объяснительная вспомнилась
CitizenOfDreams
По-моему, он там не "пид-регулятор насоса" хотел напечатать...
Dr_Faksov
Так импидор же!
cry_san
А если ввести имхо - сработает?