Виталий Филатов: заметки с тегом кровавый энтерпрайз

Кейс с совпадающими номерами

Виталий Филатов — Thu, 19 Jun 2025 22:06:29 +0500

История про совпадения в номерах стикеров и понимание коммуникационной задачи. И почему нельзя просто так взять и сделать правильно.

Рабочие макеты под NDA, поэтому в этот раз только текстом.

Ситуация

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

Чтобы человеку было удобно, разработчики придумали интерактивный чек-лист с нужными товарами и номерами стикеров. Абстрактно список выглядит так:

1245642 9258
9008731 9685
5748202 4973
4505331 9685
2356911 6736

Там ещё есть чекбоксы, фотки и названия товаров, но про макеты я уже говорил, просто представьте, что они там есть. Четыре последних цифры выделены — пользователям удобно по ним ориентироваться.

Фишка в том, что эти «хвосты» в большинстве случаев уникальны, но иногда совпадают у разных номеров, как в примере выше. И это проблема: пользователь может спутать, наклеить не тот стикер, и товар не примут.

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

Формальное решение

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

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

Теперь можно сформулировать коммуникационную задачу и начать думать. Задача коммуникации простая:

Обратить внимание пользователя на разные номера с одинаковыми «хвостами» и помочь не спутать стикеры

Очевидно, что в контексте задачи выделять «хвосты» цветом — плохое решение: мы привлекаем внимание к какому-то искусственному признаку, а не к важному. Как чиновники, когда подсвечивают знак пешеходного перехода вместо самого пешехода (смотри бессмертную заметку Лебедева).

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

1245642 9258
9008731 9685
5748202 4973
4505331 9685
2356911 6736

Выглядит так себе, но задачу решает.

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

9008731 9685 ⚠
5748202 4973
4505331 9685 ⚠

Спорно, конечно, но хорошее визуальное решение найдёт дизайнер, нам важнее показать общий принцип.

Системное решение

Всё по ТРИЗ: масштабно и безответственно. Изменить алгоритм генерации номера, чтобы исключить возможность путаницы. Например, генерировать номер так, чтобы в одной поставке не было одинаковых «хвостов».

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

0000—9999 — 10 000 вариантов, 10 в 4 степени
0000—FFFF — 65 536 вариантов, 16 в 4 степени

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

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

UPD. Статье нужен какой-нибудь афористичный вывод, так что вот он: продукт нужно проектировать до того, как он начнёт приносить прибыль. Потом уже будет не до этого.

Заявка с пятью полями загрузки

Виталий Филатов — Sat, 18 Feb 2023 01:36:02 +0500

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

Коллеги показали заявку на подключение какого-то нового дополнительного сервиса. Всё под NDA, поэтому вот общая идея в условном дизайне:

Оформление чего-то требует множество всякого

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

Тупость

Форма выглядит как плод технозависимого мышления, рождённый без любви:

В UI-ките есть компонент загрузки файла.
В бизнес-процессе документы делятся на категории.
Под каждую категорию нужно отдельное поле.

Но такое решение удобно только разработчикам. Любой выпускник UX-курсов скажет вам, что у формы проблемы:

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

Непредсказуема. Четыре поля принимают по одному файлу, а пятое — несколько. Что будет, если закинуть два файла в одно поле? Оно возьмёт только первый или выдаст ошибку на все?

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

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

Сострадание

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

Так бы мог выглядеть Степан, носи он зелёную рубашку. Оригинал на Unsplash

Пользователи редко называют файлы вменяемо, поэтому набор документов для Степана может выглядеть так:

Снимок.PNG

14512320230217.pdf

Сканы_володе_новый (2).PDF

s77x1XSLkU2F.jpeg

Павленко ДЮ — доки по кредитам.zip

У компании миллион клиентов, и даже на побочный сервис заявки пойдут плотным потоком. Среди заявок будут неполные, с грязными сканами и файлами неверного формата. И если Степану придётся открывать каждый файл и назначать категорию, он быстрее потускнеет и выгорит.

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

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

Дело в том, что IT-гигант может всё, но отдельно взятая команда разработчиков не может ничего сверх предписанного.

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

Да что там нейросеть. Команда и поведение поля загрузки не сможет изменить, потому что это поле — часть UI-кита. А китом занимается другая команда, со своим бэклогом, техдолгом и легаси.

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

Получается, что дизайнеры рисуют пять полей из любви к человеку Степану. Чтобы снять с оператора хотя бы самое тупое, дизайнеры идут против идеалов UX и перекладывают разбор файлов на пользователя. Это оправданная жертва: у Степана тысяча заявок в день, а у пользователя — одна в год.

Тут должен быть вывод, но у меня есть только афоризм:

Корпорация сильна, но человек в ней слаб и одинок.

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

Технический долг и легаси на примере тараканов

Виталий Филатов — Mon, 11 Jul 2022 01:03:41 +0500

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

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

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

Вот пример с метафорой, пока без тараканов.

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

Для пробы Никодим застилает полы в одной комнате. На этом этапе старый пол ещё можно снять и залить стяжку, но результат выглядит прилично. Так что Никодим решает идти дальше: достилает остальное, ставит межкомнатные двери и шкаф-купе, а после перевозит мебель с прежней квартиры.

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

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

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

Легаси неизбежно в любом продукте. Языки программирования и технологии устаревают, разработчики ленятся писать документацию, а потом выгорают и увольняются. Бывает, что древняя часть программы сразу получилась хорошо и стабильно работает, если её не трогать.

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

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

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

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

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

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

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

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

Никодим и утекающие абстракции

Виталий Филатов — Sun, 07 Nov 2021 02:17:46 +0500

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

Картинка Ulv Vild

Никодим устроился в IT-корпорацию писать высоконагруженный бэкенд. Его перевезли из провинции, встретили в фойе небоскрёба и отвели в переговорку на 21 этаже. Эйчар улыбалась и онбордила Никодима без умолку.

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

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

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

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

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

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

В конце испытательного срока Никодим получил письмо с паролем от лифта, который привёз его куда-то между 88 и 89 этажом.

— Привет, я — ведущий теневой зодчий, — представился незнакомец.

— Тебя нет в оргструктуре, — ответил Никодим, — это ты мой руководитель?

— Верно. Я следил за твоей работой и очень доволен. Тебе пора выходить к нам.

— Нет, — твёрдо ответил Никодим. — Тогда я окажусь в одной из вертикалей и не смогу ничего сделать.

В лифте Никодим обернулся.

— Почему гостевой пропуск не привязан к дате?

— Из-за безопасников. Они готовят их от недели до месяца и никогда не попадают в даты визита. Только так мы и смогли тебя протащить.

Никодим кивнул и двери лифта закрылись. Больше зодчий его не видел.