Чужой против хищника, или Алгоритм против Uх'а
Почему? Потому что так построен бизнес-процесс. Крайне редко бизнес-процессы в компаниях строятся, как дом, по чертежам. Чаще всего они растут, как деревья: постепенно, под влиянием 100500 факторов внешней среды — ветра, града, оползней, засух и соседних деревьев. А вы когда-нибудь видели логичное дерево? Внедрение любой алгоритмизированной системы управления (от разработок Тейлора в начале XX века до модных Kanban-досок) все равно всегда и везде работают только с адаптацией к условиям конкретной компании. Самый яркий пример — японская модель организации производства даже в рамках японских предприятий работала только в Японии. Просто потому, что была сформирована в условиях определенной однородной среды — с однородными культурными, социальными и логистическими факторами. Скопированная от и до на производстве в любой другой стране (даже, например, в достаточно схожей с Японией Южной Корее) она давала всегда настолько катастрофичные результаты, что многие отделения японских производителей закрывались в первые два-три года, пока все концепции не стали адаптировать и подстраивать под другие внешние условия.
Нечто подобное происходит и сейчас. Вроде есть красивый бизнес-процесс, кропотливо нарисованный бизнес-аналитиком для последующего создания ИТ-системы после разговоров с пользователями и изучения регламентов (сейчас мы говорим о практически идеальной ситуации). Пользователи посмотрели на него и согласились, что да, как-то так мы и должны работать. Проектируется, разрабатывается система и... дальше мы сталкиваемся с двумя растрирующими всех ИТ-разработчиков, руководителей проектов и аналитиков сценариями:
- Пользователи вежливо благодарят, принимают в эксплуатацию и... продолжают работать через ватсап, мессенджеры, почту или вообще предпочитают личное общение.
- Пользователи говорят: все отлично, только вот тут, тут, здесь, вот так и еще во-о-от там надо переделать.
Что произошло, они же сами согласились, да и вообще... почему так?
- Потому что когда система создается по регламентам, которые обычно пишут, всё должно быть «в общем и целом».
- Система создается исходя из формальной и часто достаточно линейной логики, когда аналитики и разработчики предлагают более прямой и вроде как правильный вариант, который, вот беда, не учитывает множества вариантов и факторов (помним про дерево, да?), которые со стороны не существенны, но в совокупности могут иметь слишком большое значение.
- Пользователи врут))) Ну, потому что…. тут много вариантов. Хотят выглядеть более правильными, более умными, не хотят показать, что действуют вразрез с регламентом…
Вот тут и выходят на арену те самые soft-skills, про которые я писала в прошлой статье. А именно — умение задавать вопросы не только про то, «как надо?» и изучать документацию, но и про то, «а как есть?», «а что неудобно?», «а чего не хватает?», «а что нравится?». В идеале — реально, шаг за шагом, проходить и руками проверять работу «в полях».
А вот тут может быть множество сюрпризов. Например, я лично работала в системе, где надо было из списка выбирать определенный набор показателей («достижений»), которые давали серьезный бонус к баллам для прохождения конкурса. По каждой номинации конкурса был определен свой набор, направлений было много, набирать под каждое из них следовало индивидуально. В общем, работа была довольно механической и требовавшей внимательности и быстрого манипулирования мышкой. Так вот, разработчики задали определенный средний темп работы и запоминания набора показателей, с определенными временными промежутками. сохранявшими результат. А когда я, набив руку, стала вводить слишком много достижений в промежуток, система сочла, что подвергается атаке или работает бот, и просто обнуляла наборы, которые я делала до этого.
Второй тонкий момент — острое желание, особенно у молодых разработчиков и аналитиков, «спрямить» существующие процессы, сделать их эффективнее, логичнее и короче. «Причинить добро» на всю катушку, в общем. При этом они не учитывают множества факторов, которые могут и влияют на процесс «под капотом». Про них не говорят, потому что они привычные, часто «само собой разумеющиеся» для тех, кто находится внутри процесса, да и вообще — во внутреннюю кухню не все готовы посвящать посторонних.
И тут ничем, кроме как мягких навыков, не поможешь — начиная с аккуратных расспросов «за чашкой кофе» и просьбами «научить» и заканчивая суровой модерацией попыток объяснить пользователям, как им лучше жить. Потому что часто попытка показать «как лучше жить», возвращаясь к нашей аналогии с деревьями, превращается из обрезки сухих ветвей и подстрижки кроны в обтачивание ствола и повреждение корней дерева.
Возвращаясь к предыдущей статье: мягкие навыки — это не только про умение говорить словами через рот, но и про умение слушать и слышать. Причем оба умения работают только в связке.
Хорошая и яркая коммуникация, позволяющая прогнуть пользователя на неудобные решения, в итоге выливается в крайне плохие кейсы и реверансы, а неумение донести полезность тех или иных корректировок в бизнес-процессах порождает автоматизацию бардака.
