TGViewer
Products | People | Process Products | People | Process @program_man · 854 subscribers
Post #204 970
Помните смешной текст про то, что все животные делятся на
- принадлежащих Императору;
- набальзамированных;
- прирученных;
- молочных поросят;
...

?
Это Х.Л.Борхес так пошутил, а для нас иллюстрация плохо структурированных категорий.

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

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

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

Чтобы такого было поменьше, лучше делать хорошие категории по принципу MECE, mutually exclusive and collectively exhaustive. То есть одновременно взаимно неперекрывающиеся и совместно полные. То есть мы каждому предмету можем присвоить категорию и ровно одну. Можно конечно сделать подкатегории следующего уровня. Как в биологии - виды/рода/классы/... но на каждом уровне тот же самый принцип.

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

Конечно, есть способы и инструменты передавать сложную информацию - можем рисовать графы, и как между ними перетекают объекты. Люди, которые в этом варятся постоянно даже придумают какие-то собственные метрики и концепции, чтобы с этим жить. Но все-таки простая воронка для приведенного примера проще хитрых графов, все будет понятно в ситуации "должны были позвонить -> планово позвонили", 7 из 9, все понятно.

Наверное, надо в другой раз полнее развернуть про паразитную когнитивную нагрузку
  • 👍 12
  • ❤ 1
More from @program_man
  1. Sep 30, 2026Ушла эпоха. Помните часто говорили, что русский это 2й после английского язык в инете? Сов…
  2. Sep 17, 2026Коллега принес новость, которую я упустил, и мнение, с которым, я согласен. Новость была ч…
  3. Aug 12, 2026Когда ИИ полтора года назад был еще довольно хромой, для меня было актуально сравнение с и…
  4. Aug 5, 2026На неделе возникла мысль в обсуждении о внедрении ИИ в организациях, что есть мощный огран…
  5. Jul 31, 2026Помню довольно болезненное открытие разницы мышления инвесторов и управляющих. Вот приходя…
  6. Jul 16, 2026Попался изящный способ развести Клода на данные владельца. ИИ довольно много со временем н…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →