Мне нравится порядок, в котором устроены руководства, и порядок, в котором даются задания.
Прошлое задание про поиск целевой системы вызывало ряд дребезгов и неуверенностей. Я там не получил никаких комментариев, поэтому с небольшой долей уверенности буду считать, что целевую систему тогда нашёл правильно — как «сервис автоматизированного сбора платежей». Но сомнения есть, и мышление по мантре должно помочь разобраться.
После того как мантра «была выдана» в руководстве, появилось призрачное ощущение того, что теперь будет проще думать о целевых системах и искать их. Это именно «призрачное ощущение», и до метанойи тут ещё далеко. Про метанойю буду говорить, когда я на автопилоте, без подглядывания в заметки с мантрой, буду по этой самой мантре мыслить.
Формулировка «возьмите какое-то одно звено» пока вызывает ступор, потому что я до сих пор словно не получил внятного ответа на вопрос: «Выходит, что можно делать zoom-in, zoom-out и брать за целевую систему разные системы в рамках моделирования на разных системных уровнях?»
Если пытаться ответить, то ведь можно. Почему нет? Иначе зачем всё это вообще? И помню про безмасштабность.
В последних материалах про роли и функции жирно подчёркивается важность контекста, и важность контекста — это не про перевёртыш «термины важны и не важны». Контекст важен абсолютно всегда. Системный уровень важен абсолютно всегда. Эти границы надо чётко находить, понимать и думать в их рамках.
Я думаю так: если на каком-то уровне есть создатель, роль, процесс/поведение, по которому создатель создаёт нечто, что является конструктивом-аффордансом для функционального объекта::система, который уже, выполняя свою функцию в какой-то точке пространства-времени, оказывает некое полезное влияние на физический мир, то про целевую систему тут говорить можно, так? Да… нужно!
Но я словно упускаю до сих пор что-то. Но что?
Ну например, я хорошо помню из «Рац. Работы» про граф создателей, да и в R5 это часто повторяют, и то, что целевую систему нельзя путать с описаниями или с конструктивами, которые создаются как аффордансы для подсистем целевой системы.
Непонятно, про какие звенья мне сейчас надо думать.
Быть может, если бы я заправлял конвейером по штамповке сепулек, мне было бы немного проще? Не уверен.
Попробую наконец пройти по мантре.
Что надо изменить в окружении целевой системы?
Сначала я подумал что-то вроде: «В окружении целевой системы надо изменить уровень фрустрации лиц, ответственных за финансовые B2B-отношения, упростить им работу по методам сбора задолженностей, выставления счетов-инвойсов, ведения учёта цифровых двойников физических инвойсов и новомодных e-invoices».
При повторном проходе — фрустрация не физична. Фрустрация — это эффект, и не очень-то “окружения”, а скорее психологический эффект у каких-то агентов в этом окружении. Поэтому тут надо заземлиться. От чего в физическом мире возникает фрустрация, откуда ноги растут? Ноги растут от состояния дебиторской задолженности — требования об оплате должны быстрее и надёжнее доставляться должникам, проходить через смену состояний: из «выставлено / ждёт оплаты / просрочено» в «оплачено / учтено», например.
А вот уменьшение фрустрации и уменьшение ручной координации этих переходов, чреватой кучей ошибок, — вот это уже эффект, которого надо добиться.
Каким способом/методом меняем окружение целевой системы?
Вот тут я задумался. Автоматизация::сервис, предоставляющая понятные средства и представления для выполнения работ по знакомым методам агентов из окружения целевой системы, — это способ/метод?
В этом месте у меня совсем всё разрушилось в голове, и я обратился за помощью к FPF.
FPF сказал, что я начал путаться в типах и использовать плохие формулировки, вроде зонтичного термина «автоматизация» и полисемичного — «сервис».
Сложно согласиться! Но хорошо, что мне хватило внимания к себе, к распознаванию дребезга.
Так каким же способом/методом меняем окружение целевой системы?
Способом/методом — «проведение требований об оплате через цикл сбора задолженности (collection-flow)», который включает в себя подспособы/подметоды:
-
создание и поддержание цифрового двойника счёта;
-
доставку требования должнику по подходящему каналу связи;
-
предоставление способа оплаты долга;
-
напоминание и эскалацию (chasing);
-
обработку ответных сообщений и возражений;
-
фиксацию поступления денег и синхронизацию с внешними учётными системами.
И тут сразу переходим к роли.
Какова роль целевой системы?
Роль системы можно назвать как-то так — «собиратель платежей по дебиторке».
Почему это функциональный объект / роль? Ну он прямо функциональный 
На эту роль можно назначить аффордансом «Васю», который будет сидеть и малоэффективными средствами обзванивать и обписывать контрагентов, культурно требуя заплатить деньги. А можно назначить систему Octa Core, заколотить в неё своих клиентов, быстро настроить интеграцию с платёжной системой, расписание выставления платежей — и она начнёт делать всё, что может, по роли «собиратель платежей по дебиторке».
А еще кажется что на 100% оно само всё-таки не может, есть спорные пограничные случаи, поэтому правильным аффордансом на эту роль вдруг может оказаться киборг Вася + Octa Core, но тут я не уверен)))
Из чего будем делать целевую систему?
Целевую систему будем делать из программного комплекса::система, реализующего автоматизированные системы, задачами которых являются:
-
исполнение подролей роли «собиратель платежей по дебиторке»;
-
интеграции с внешними платёжными системами;
-
интеграции с каналами связи;
-
реализации моделера-интерфейса для настройки поведения целевой системы.
Конкретнее — из чего целевая система сделана-то?
Из:
-
программных компонентов;
-
модели данных;
-
адаптеров для интеграций с внешними системами;
-
интерфейсов настройки, наблюдения и использования.
Что ещё нужно для того, чтобы система работала?
Нужны:
-
инфраструктурная платформа;
-
система сборки, доставки и развёртывания изменений;
-
система мониторинга / наблюдаемости и обратной связи;
-
внутренние конфигурации.
Какими методами работы делаем целевую систему?
Целевую систему Octa Core делаем методами разработки продуктовых программных систем.
Какие это методы? Ну, одним «написанием кода» тут не обходится и никогда не обходилось.
Нужны:
-
разработка концепции использования на основе реальных use-cases по сбору задолженности;
(это прямой ход обратно на первый пункт мантры, чтобы разбираться снова и снова, что там в окружении и что должно меняться); -
разработка концепции системы и функционального устройства Octa Core;
-
принятие архитектурных решений по данным, интеграциям, надёжности и изменяемости;
-
инженерия платформы сборки, доставки, конфигурации и эксплуатации;
-
кодирование как реализация поведения системы в коде и моделях данных;
-
испытания и инженерные обоснования того, что система действительно выполняет нужную роль;
-
сопровождение и непрерывное развитие по обратной связи из рантайма.
И вот тут я снова стал путаться — натыкаться на мысли: «а как же продажи, маркетинг, онбординг, customer support и вообще инженерия самой организации? Нам же дальше надо будет на роли создателя отвечать. А разве создатель тут — только программисты и технари?», и я опять пошёл в FPF.
На что получил ответ, коротко: я уже в своём моделировании по мантре выбрал де-факто более узкое звено, и это правильно. Описывая методы создания и развития, некорректно мешать тут разные звенья из графа создателей.
Пока я писал предыдущее предложение, чуть не хлопнул себя по лбу. Ну конечно! Что надо понимать под звеном, то есть под моими вопросами и сомнениями в начале поста? Подсистему-создателя системы в графе создателей целевой системы. Задание же именно это и требует сделать.
Я в большей мере играю до сих пор роли как раз в «техническом звене», несмотря на мои попытки выйти в другую ветку, поэтому продолжу думать по мантре об этом звене.
Какова роль создателя?
Роль создателя тут — инженер, а точнее инженер продуктовой программной системы.
Кто/что будет создателем?
Эту роль выполняет команда из нескольких агентов, которые выполняют, должны выполнять, роли-специализации. Но это уже провал на вложенный уровень, так что всё-таки организованная команда из нескольких агентов будет создателем.
Дополнительные вопросы
О чём пришлось подумать впервые, если не пропускать шаги рассуждения?
Сразу с самого явного — о явном разделении звеньев, не интуитивном, не контринтуитивном, а просто тупо явно типизированном, хотя бы как-то.
Мантра заставляет думать сразу про «параллельные» ветки графа неизбежно, но надо отделять одно от другого, не мешать типы, роли и уровни.
Мантра заставляет спотыкаться, да. Такой «спотыкательный waterfall мышления». Даже если ты знаешь про следующий пункт наперёд и можешь в него свалиться, пока думаешь по предыдущему, — это ничего. Но вот если ты не сваливаешься, а вообще застопорился, то, скорее всего, в предыдущем пункте было подумано «не то и не туда», напутано. Я дважды обращался к FPF, чтобы уточнять себя и исправлять ошибки.
FPF + мантра — это мощнейший инструмент. А FPF + мантра + интернализация в свои мозги через мышление письмом, а не копипасту, — это вообще сказка.
Что надо поменять в проекте, чтобы использовать результаты прохождения этого системного рассуждения по системной мантре?
Это системный вопрос. Использовать как, кому? Под использованием предполагается прагматика — чтобы от использования был толк.
Сказать честно: чтобы это использовалось максимально качественно в проекте, мне надо поменять свою роль, и желательно сразу на CEO/CTO. Думаю, не надо объяснять тут, что в стартапе такую смену власти провести невозможно. Значит, надо менять проект
Ну а если без крайностей и по существу, то в проекте, конечно, надо менять методы работы. Если мы рассматриваем только техзвено, которое я тут моделировал, — то это самая большая беда.
Единственный метод, в котором сейчас я как агент и роль пересекаюсь с другими членами команды, — это «кодирование как реализация поведения системы в коде и моделях данных», с большой оговоркой, что без реализации описаний остальных методов, без начала работы по остальным методам и без обучения других агентов всем перечисленным методам кодирование и остальные связанные работы по «соседним» методам выполняются в формате вошкания, со всеми вытекающими.
Я предполагаю, что мне нужно провести моделирование ролей, а не только методов. Ну а как это моделировать в отрыве? Ещё предполагаю, что нужно продолжать проводить смену аффордансов на подроли основной роли-создателя. Этот процесс уже происходит, но темпы не лучшие.
Ооо, мантра системного мышления заставляет думать буквально во все стороны. Даже в рамках одного звена находится, что сделать.
Что и кому надо предпринять, чтобы повысить шансы успешности проекта?
C-level-костяку — осознать ошибки в своём мышлении и стратегировании, услышать голос сбоку-снизу, то есть мой.
Непонятно, сколько усилий с моей стороны нужно продолжать предпринимать. Я отдаю себе отчёт, что это, пожалуй, самая сложная задача — переубедить кого-то, показать и доказать дребезг. Но вообще, наверное, надо всё-таки быть рациональным тут в плане инвестирования собственных ресурсов.
Разумеется, я ещё не обладаю многими мастерствами, и, конечно, есть способ «переубедить», привлечь внимание, договорить. Мне с этого сейчас только опыт. Но в чём именно? Правильно ли я вообще практикую переубеждение / привлечение внимания / договаривание / доказывание — я не знаю.
В частности, что надо предпринять лично вам?
В частности, лично мне надо ещё несколько раз попытаться донести рациональность предлагаемых изменений, а дальше — либо внедрить эти изменения, либо сменить проект.
