О системах и ситуациях их эксплуатации
Системы, в создании которых участвует ваше предприятие, обычно используются за пределами предприятия. То есть, есть агенты, которые берут созданную вами систему и в ходе действий используют её для чего-либо. Например, Wi-Fi инженер берёт электронный картограф и строит карту покрытия склада Wi-Fi сигналом. После чего карту получают монтажники, которые будут устанавливать оборудование так, чтобы Wi-Fi был доступен из любой части склада. Соответственно, электронный картограф должен выдавать описания, которые будут полезны и нужны не только Wi-Fi инженеру, но и монтажнику, работающему с конкретным оборудованием из каталога производителей.
Если вы хотите описать ситуацию использования/эксплуатации системы, вы должны назвать:
- систему, которую вы создаёте;
- агентов, которые будут использовать систему (часто называются каким-то специальным словом, например, Wi-Fi инженер);
- действия агентов по эксплутации системы;
- условия эксплуатации системы:
- место, где эксплуатируется система;
- время, когда используется система (период) или событие, к которому приурочено использование системы;
- (опционально) частоту использования системы.
- почему эта система полезна/необходима для агентов-эксплуатантов.
Затем можно описать, что изменилось:
- в мире после действий агента-пользователя системы,
- у самого агента-пользователя системы и у тех, кто будет получать пользу от результата.
Фактически, вы описываете сценарий использования системы, как будто вы смотрите кино. Возьмём, например, телеком-компанию, которая изготавливает систему типа «сеанс связи» (между абонентами сотовой сети). Можем думать об этом так: 20 мартобря 20ХХ года в 17:33 дочь звонит матери, чтобы узнать, как у неё дела. Они разговаривают 20 минут, после чего отключаются. Такие разговоры происходят несколько раз в неделю. В результате и мать, и дочь после таких сеансов связи спокойны и уверены, что всё хорошо, или договариваются встретиться через неделю.
Ситуация эксплуатации системы может быть далеко от вас, если вы изготавливаете описания. В таком случае вы можете воспользоваться этим алгоритмом, чтобы описать сначала ситуацию использования вашего описания, потом – описания, изготовленного при помощи вашего описания, пока наконец вы не доберётесь до ситуации эксплуатации конечной системы. Вернёмся к примеру с заключениями о безопасности проектных решений, представленных в документации (проектной, сметной, исходно-разрешительной) объекта капитального строительства (ОКС). Вы выдаёте заключение о том, что конкретное проектное решение безопасно. Заключение получают проектировщики и передают регулятору (органу надзора), чтобы он разрешил строительство описанного объекта. После чего используются другие описания для того, чтобы появилось студенческое общежитие. Эту цепочку можно описать кратко, как сделано выше, или расписывать подробно по алгоритму. Когда вы тренируетесь описывать систему и ситуацию её эксплуатации, можно расписывать поподробнее, чтобы «увидеть» ситуацию эксплуатации в вашей голове. После можно будет сократить такое описание.
Как рассуждать, чтобы найти систему? Во-первых, ищем конечные системы (физические объекты, которые используются для удовлетворения нужд агентов непосредственно, напрямую), во-вторых, пробуем описать ситуацию(и) эксплуатации системы и пользу от неё. Например, выдаем заключения о безопасности проектных решений, предложенных для строительства общежитий – системой считаем общежитие, используется оно для проживания студентов из других регионов, чтобы они смогли сосредоточиться на учебе. Или мосты, которые построены по 3Д-моделям и используются для перевозки грузов и пассажиров через реку. Обратите внимание: вы ищете систему и описываете, как она используется. Почему так? Потому что система всегда по умолчанию интересует нас в момент эксплуатации (даже если он ещё не наступил). Систему мы всегда определяем и называем по тому, что она делает (какую функцию выполняет) в тот момент, когда её эксплуатируют (или будут эксплуатировать) пользователи. Потому что система нужна для того, чтобы приносить пользу, если она не приносит пользу, то она не нужна, за неё перестанут платить (и будут правы!), она будет валяться, как ваши забытые вещи в подвале.
Любимая ошибка инженеров-менеджеров: считать «системой» то, что мы создаём, а всё остальное «далеко и нас не касается». Если вы в современном мире хотите иметь успешную карьеру или совершать прорывы в бизнесе, недостаточно «просто хорошо выполнять работу». Например, недостаточно только хорошо писать код – в лучших продуктовых компаниях инженеры-разработчики участвуют в продуктовых исследованиях/product discovery[1]: чтобы разработать хорошее техническое решение, они тоже должны видеть, как пользователи используют продукт, как они думают, и так далее. То есть, разработчики должны разбираться в предметной области, для которой они пишут код. Например, вы создаёте ERP-систему, которая отражает поток лекарств, проходящих через аптеку, и поток ресурсов, который проходит через рабочие станции аптеки[2]. В этом случае для создания действительно хорошего софта и победы в конкурентной борьбе вам придётся разобраться в предметной области фармацевтики: какие лекарства сейчас активно покупают (а какие нет), какие лекарства служат дополнениями (комплементами) к другим и их нужно запасать и предлагать покупателям совместно, как нужно размечать и хранить эти лекарства, когда сигнализировать об истекании сроков годности – чтобы фармацевтам, которые будут пользоваться ERP-системой, было удобно работать.
Соответственно, умение выделять систему и моделировать граф создателей системы (производственную цепочку), определять ваше место в ней необходимо, если вы хотите успешно продвигаться в карьере. Также во многих случаях вам придётся разбираться в предметной области клиента: если вы не понимаете, как используется ваша система, как вы вообще можете сделать хорошую систему, за которую заплатят? Как вы можете быть уверены, что не делаете ерунду, если не вычислили систему?
Систему не следует путать с действиями по использованию (и тем более созданию) системы. «Электронный почтальон», который компания использует для доставки электронных писем вовремя и без сбоев – это сама система, которая в момент эксплуатации разносит письма[3]. Но это не функция «принесение письма» (и тем более не письмо, которое принёс почтальон)! Это не действия по созданию такого «электронного почтальона»! Нам важно, что есть агент, который выполняет некоторое действие: электронный почтальон, ИИ-нормоконтролёр, и так далее.
Как определить, имеете ли вы дело с системой/физическим объектом или действием:
- попробуйте определить, что произойдет, если всё замрёт (вспомните детскую игру «Море волнуется раз»). Если всё замирает – и штука, выделенная вами как «система», исчезает (эффективность не повышается), то вы, вероятно, выделили действие/исполнение;
- ответьте на вопрос: можно ли сделать фото, которое отражает систему, или требуется видеозапись? Например, фото общежития можно сделать, а вот чтобы показать процесс строительства, нужно видео;
- назовите агента, который что-то делает с системой. Отличайте при этом «поведение существования системы» (общежитие «начало» существовать 14 мартобря 20ХХ года и закончит когда-то в будущем) и «(активные) действия агента (с системой)» (студенты живут в построенном обжещитии). Что «происходит» (и кто это делает), а что «существует»?
- есть ли у выделенного объекта границы? Он продолжает существовать, даже если ничего не делается? Если да, то это система, а если нет, то, скорее всего, это что-то другое.
Continuous Discovery Habits – Teresa Torres ↩︎
https://systemsworld.club/t/zadanie-9-3-iz-rukovodstva-1-raczionalnaya-rabota/26401 ↩︎
https://systemsworld.club/t/raczionalnaya-rabota-igra-nazovi-veshhi-2/31735/7 ↩︎