Правила созданы для того, чтобы их нарушать, слышали такое?
Не менее актуально это звучит в эпоху AI, скорее наоборот.
У кого-то одна только мысль о нарушении правил может вызвать сильное бурление из-за несостыковки представлений – “правила нарушать нельзя!!!”
На эту тему можно спекулировать слишком широко, но сегодня нас интересуют именно формальности в организации работы и ее методов. Это про всех – живых и неживых агентов.
Беда в том, что сам мой посыл уже ошибочен.
Пусть даже мы определим контекст еще более конкретным, например — организация работы в команде, которая разрабатывает AI-продукт.
Тут все еще недостаточно приближения для формализации. Ибо работа неотрывно связана с агентом, который ее выполняет, и его ролью.
Помимо функционального рассмотрения роли нас интересуют и другие «штуки». Например, какие у роли интересы и предпочтения? Что ей важно для работы, а что нет? Есть ли в ее методах работы опасность (нужно учесть все риски), и многое другое в зависимости от прикладной области.
Игра в онтологическое моделирование сложна, из простого в ней только одно — если начинаем играть, то играть надо хоть сколько-нибудь по-взрослому, в нескольких размерностях. Иначе ерунда.
Нахватавшись и напихав в головы несколько представлений, методов из популярных учебников, будь то Agile, DevOps или любых других модных и хороших практик, без детального объяснения того что мы делаем, как делаем, зачем, и кто и что именно должен делать, почему именно эти методы выбраны в компании, мы поедем… я не знаю куда, ну… куда-то! В лучшем случае это движение наощупь, в худшем – вообще непонятно куда.
Многих такая масштабность и сложность онтологического моделирования пугает — “Ууууух, блин, это сколько надо подумать и продумать! Да и вообще это вот щас гестапо правил будет, кошмар бюрократический, нам бы погибше да попроще быть”.
В смысле гибкости и сложности – все наоборот.
Любые формальные описания методов работы неизбежно подвергаются изменениям при всего лишь паре условий: • Есть кто-то (роль, агент) кто должен следить за исполнением методов и собирать метрики • Целью всего моделирования было не само моделирование, а благородная направленность на изменение качества и эффективности работы – применяем что намоделировалось.
Все это очень гибко и бурно меняется на начальных этапах, когда модель сырая и было собрано слишком мало фидбека от агентов-исполнителей — естественно, мы заинтересованы (должны быть) как можно быстрее нашу модель сделать удобной и понятной для всех. Иначе какой вообще смысл?
Понятность и прикладная применимость, полезность модели характеризуется ее разделяемостью — имеется в виду, что модель понятна и полезна разным агентам в разных ролях.
Ничего, кроме взрослого моделирования методов работы (особенно когда в процессы интегрируется AI – им так же детально нужно на символьных описаниях объяснять что делать и как), не даст нам настоящего буста в эффективности, скорости доставки и всего желанного прочего.
Верить, что можно затыкать дыры “гениями которые сами разберутся”, просто некорректно, потому что каждый такой “гений” все равно говорит на своем языке — на языке своего семантического общества (как минимум менеджер на менеджерском, а инженер на инженерном). И тут модель предприятия, онтология и набор методичек по работе как минимум поможет им заговорить на одном языке. Это уже очень много, в смысле эффективности.
Взрослая системная инженерия, формализация процессов/методов не просто не боится нарушений формальностей — она предвосхищает их и ставит на высокий пьедестал ценности как очень нужный и важный материал, потенциал, бесценную возможность улучшить саму модель путем ее уточнения (да хоть полного переделывания, если придется), тем самым улучшая как весь жизненный цикл предприятия, так циклы отдельных кусочков, и рабочий опыт вообще.
О да, думать придется дохрена, зато какой результат!