Мастерство как система
Для того, чтобы клиент смог получить результат оргпроцесса, выполняемого каким-то оргзвеном в своей оргроли (например, внутренний клиент сможет получить зарплату::деньги::система, начисленную::оргпроцесс::поведение и выданную::оргпроцесс::поведение бухгалтерским отделом::оргзвено как казначейством::оргроль), приложение/программу/софт::система нужно настроить, добыть для него исходные данные, научить работать с использованием этого софта как инструмента сотрудников (вот буквально как ребёнка учат молотком забивать гвозди --- гвозди не мимо нужного места, а молотком бить не по пальцам, вот так и учат использовать софт), а затем проверить не столько софт, сколько работу всегооргзвена/службы/провайдера в целом, включая приданный этому оргзвену софт. Софт при этом вроде как входит в состав подразделения примерно так же, как молоток входит в состав оргзвена каких-нибудь кровельщиков, которые с его использованием будут изготавливать крышу здания.
В современном мире может быть и наоборот, оргзвеном выступать софт, а в его состав будут включены какие-то люди (операторы, команда разработчиков), но требоваться будет всё равно работа не только одного софта, но и входящих в его состав людей.
Повторим: никого не волнует отличная работа программы начисления зарплаты, волнует само начисление зарплаты (можно представить его как деление какой-то кучки физического золота на предназначенные для раздачи сотрудникам части) --- и если начисления зарплаты не произойдёт, то программистам команды создателей софта трудно будет объяснить не получившим свои деньги сотрудникам, что с их программой всё в порядке, а неправы все остальные сотрудники отдела бухгалтерии, неправильно заполняющие поля этой программы и нажимающие не те кнопки. Сотрудникам всё равно, софт внутри бухгалтерии или бухгалтерия внутри софта, их волнует результат работы софта в конечном итоге!
Вы приглашаете к себе экскаватор рыть траншею, и приданного к экскаватору экскаваторщика (человека, который играет роль экскаваторщика с его экскаватором)? Или приглашаете экскаваторщика как подразделение из одного человека, в состав которого входит заодно и экскаватор? Я думаю, что вам проще считать, что есть подразделение-экскаватор, а в его состав входит ещё и управляющий человек, «софт управления экскаватором, исполняемый живым компьютером». Важен не сам экскаваторщик, а его экскаватор, результат ожидаем от экскаватора! В операционной нам обычно важен хирург и анестезиолог, а вот в кабинете компьютерной томографии --- прежде всего томограф, а что там сменные бригады операторов при нём --- это где-то внутри томографа как подразделения, состоящего прежде всего из томографа и нескольких человек в нему впридачу.
Если у вас в компании AI-агенты или мощный серверный софт, который даёт основные результаты, то обычно непонятно, приписываете ли вы этот софт (включая AI-агентов) к людям, или наоборот --- людей к софту. Люди в этом плане --- тоже «универсальные роботы, у которых внутри специализированный софт по работе с другим софтом или оборудованием».
В проектах по разработке программ/софта/приложений/цифровых двойников очень часто есть необходимость разрабатывать не только тот софт (традиционный или нейросетевой AI-софт), который существует в компьютерах, но и тот нейросетевой софт, который существует в мозгах людей как вычислителях. Этот софт/программу, реализующий алгоритм/теорию/дисциплину какого-то метода работы как физический объект мы будем называть мастерством выполнения какого-то «ролевого поведения»::«метода работы». «Ролевое поведение» --- это поведение агента (который состоит из организма и/или аппаратуры в случае живых агентов-людей или не очень живых AI-агентов, а также личности и/или программного обеспечения/программных средств как совокупности всего софта/программ, работающего на этом организме/аппаратуре), взятое в части поведения одного только мастерства из состава личности, которое помогает личности играть одну какую-то роль. Грубо говоря:
- Человек::агент = организм + личность (личность как совокупность самых разных видов мастерства, «весь софт, все программы для мозга»)
- AI-агент = аппаратура + личность (личность как совокупность самых разных видов мастерства)
- Мастерство::система = обычная или нейросетевая программа::система, которая работает на базе какой-то аппаратуры AI-агента или организма человека, реализует алгоритм/теорию какого-то метода/способа работы.
- Метод::поведение --- обобщённый алгоритм/теория, по которому работает мастерство, а также инструменты, которые нужны для того, чтобы метод мог быть выполненным (скажем, для метода рытья траншей землекопу кроме мастерства рытья траншей нужно иметь или лопату, или экскаватор --- инструменты, делающие возможным применение мастерства).
В проекте разработки корпоративного софта обязательно будут:
- учёт аппаратуры для этого софта («железо» или «виртуальная машина» --- контейнеризация софта, учёт того, что часть софта исполняется на сервере в датацентре, а часть может быть и на телефоне с крошечным экраном, и т.д. --- везде своё, но аппаратура должна быть!). Программа работает в составе программно-аппаратного комплекса, а не сама по себе!
- собственно разработка целевого софта, её все видят и признают.
- «изготовление мастерства в мозгах людей» (обучение работе с программой: нужно «изготовить» те части самых разных людей в самых разных ролях, которые смогут делать что-то полезное с программой --- изготовить мастерство работы с программой). Заметим, что надо будет как-то учесть и организмы этих людей, те самые «мозги людей» --- если людей вам не дали, то и мастерство вы в них не изготовите, всё то же, что с аппаратурой для «программно-аппаратных комплексов».
- Изготовление мастерства в AI-агентах (это только-только появляется, но тут будут свои особенности: нынешних AI-агентов и не запрограммируешь как софт, и не обучишь как людей, а мастерство работы с вашей программой от них потребуется)
- Изготовление исходных данных (data engineering) и разноска их по разным носителям, с которыми будет работать программа. А уж сама программа будет формировать выходные данные, и их тоже надо знать, куда и как положить.
Не пропускайте эти части! Они физичны, их тоже нужно «проектировать», а затем «изготавливать»:
- сам софт «разрабатывают» в ходе программной инженерии/softwareengineering,
- для изготовления мастерства в составе личности людей и AI-агентов их надо учить (и разрабатывать способы, которыми это будет происходить, и способы проверки научения --- подробно об этом в курсе «Инженерия личности»),
- дополнительный классический софт настраивать в части использования его интерфейсов (и проверять, всё ли настроилось).
А что же с людьми, которые работают с программами? Очень часто воплощением целевой системы проекта будет какая-нибудь часть организации, которая должна выполнить какое-то дело --- выдать кредит, начислить зарплату, изготовить деталь. И если окажется, что программа работает «правильно» с точки зрения её разработчиков, но люди в организации не могут с ней работать даже неважно по каким причинам, то не будет засчитана за правильную и работа программы. Что толку в работе программы по начислению зарплаты, если люди с ней не смогут сработать? Если программисты хотят получить деньги за свою часть работы, они должны быть уверены, что кто-то работает и с людьми, а сдаваться заказчику будет совместная система из обученных людей и настроенных программ (а также данных к этой программе, что может быть отдельной проблемой и может требовать отдельных исполнителей). Сдаваться будет начисленная зарплата, изготовленная качественная деталь --- и дальше по цепочке работа оргзвена, ведущая к этим важным целевым результатам, а внутри этой работы оргзвена (подразделения, проектной группы) будет сдаваться софт.
Для обучения людей проводите примерно такие же рассуждения, что и про компьютерные программы. Учебные книги, видео, компьютерные курсы (например, наш курс «Системная инженерия») --- это только документированные описания того, что хотелось бы получить после обучения. Целью обучения является кусок обученного мозга, назовём её мастерство::софт::система, причём работающий (система в момент эксплуатации всегда как-то себя ведёт!). Мастерство как система в момент попадания её в целевое окружение включается по аналогии с компьютерной программой, которая включается в момент попадания её в окружение её вызова в компьютере и производит те вычисления/мышление, на умение делать которые было направлено обучение. Мозг --- это вычислитель, мастерство работает как часть вычислителя. Неважно, какими конкретно частями мозга реализуется мастерство. Главное, что мастерство реализуется мозгом, а не космосом, внеземными силами, вселившимися духами и прочими не очень правдоподобными причинами. Прочтённые книги, просмотренные видео лишь задают описание того, что потребуется от мозга потом, в ситуации использования мастерства. Прочтённые книги, просмотренные видео и выполненные упражнения лишь обучают нейросетку, повышая вероятность протекания в мозге физического процесса (со сменой состояний!) мышления в соответствии с результатами обучения в ситуации использования мастерства.
Единственное что, так это не нужно говорить о нейронах и их обучении, это явно не тот уровень деталей (не тот системный уровень, не тот уровень размера систем), который обсуждается при обучении. Но представление результата обучения как обученного для работы в целевых условиях участка мозга «мастерство» заставляет продумать и то, как выглядит это обучение в физическом мире (участок мозга должен в момент обучения быть где-то расположен, должны подводиться данные и выводиться результат мышления::вычисления), и как выглядит в физическом мире работа результата обучения как системы (должно быть соответствующее физическое окружение мастерства, чтобы оно было уместно. Умение делать сальто с места неуместно под водой, но уместно в цирке).
Скажем, в момент использования мастерства человек может находиться в машиностроительном цеху, среди жуткого грохота окружающих машин. Включится ли мастерство (софт/программа нейросети/обученный участок мозга) без дополнительного напоминания? Выдаст ли в этом окружении безошибочно и без пропусков то мышление, которому его учили? Сколько времени это займёт? Что происходит до этого момента, что будет происходить после этого момента? Переход к физической системе (участку мозга, который готов действовать/мыслить) оказывается продуктивным и для ситуации обучения. В обучении много описаний, но не они оказываются главными. Главным тут оказывается результирующий физический объект: система с предписанными ей свойствами и известным поведением в момент использования.
Что является целевой системой проекта строительства моста? Мост, конечно! Но для строительства моста нужно создать организацию проекта, которая проведёт его создание, потом провести работу этой организации сначала в части проектирования (обычно в городе, в проектном институте), затем в части стройки (несколько тысяч человек в чистом поле!), и только потом получить удовольствие от моста. Это всё цепочка создания: создать создателя, потом создатель создаёт целевую систему. Это могут быть не только цепочки, но и более разветвлённые графы, и там может быть много звеньев (создатель создателя создателя). Представьте, например, любой из программистских проектов, которых много в рамках строительства моста. Зачем они существуют? Зачем этот весь софт? Чтобы в конечном итоге появился мост!
Системное мышление требует отследить всю цепочку от используемого в проекте строительства софта до самого моста. Если не отследить, то софт оказывается не нужен --- хотя разработчики очень хотят за него получить деньги, особенно за ненужные никому «фичи»/возможности этого софта. Если возможности софта не будут использованы, то они могут и не работать как надо, но деньги за них заплатят, если удастся утаить связь этих возможностей софта с реализацией целевого моста. И если окажется, что целевому мосту от этого софта с его возможностями ни холодно, ни жарко, то это будет означать, что софт можно этот и не писать, проектом этого софта не заморачиваться, деньги за него не платить. Системное мышление проверит, не занимаетесь ли вы никому не нужной работой.
Системное мышление заставляет об этом всём думать сразу, а не в момент неподписания актов приёмки-сдачи по проекту «создания программного обеспечения». Обычно сами по себе программы как системы никому не нужны, они нужны только как части каких-то других систем --- и нужно убеждаться, что разработка идёт этих других систем в целом прежде всего, а программ --- только как части этих систем или как части систем, которые делают эти целевые системы --- разбираться нужно со всеми цепочками, ведущими к реальности, к физическому миру. Не путайте фотографию и изображаемый на фотографии предмет, книгу и живой мир, который описан в книге, софт и реальный мир, описываемый и меняемый софтом.