В данном посте я собрал некоторые идеи из второй главы учебника "Системное мышление 2020", которые достаточно понятны, чтобы их уже можно было применять на практике, и которые потенциально могут принести пользу.
Как договариваться: не обобщать, а конкретизировать
Когда обсуждение заходит в тупик, когда нет уверенности, что собеседники говорят об одних и тех же вещах, то нет смысла пытаться идти в определение понятий, о которых идет речь. Нужно идти не вверх, к определениям, к классам-типам, а вниз - к конкретным примерам того, о чем говорим. Примеры объектов физичны, они понятны, на них можно показать пальцем. Таким образом понимание придет быстрее и, что немаловажно, будет больше уверенности, что понимание пришло. Беседа получится продуктивнее.
Более того, переход к конкретным примерам согласуется с рассуждениями в первой главе о том, что слова и термины не важны, когда люди пытаются договориться. Важно понимание, что люди говорят об один и тех же объектах в физическом мире. При этом слова они могут использовать разные.
Следим за системным уровнем в обсуждениях
Если обсуждается какая-то проблема, необходимо выделить уровень, на котором эта проблема обсуждается и следить за тем, чтобы собеседники не переходили на другие системные уровни (если цели обсуждения этого не требуют). Приведу недавний пример из практики.
Обсуждался дефект к системе, который был сформулирован следующим образом: "Маска в поле ввода "Номер телефона" на форме создания заявки не соответствует принятому в системе общему формату хранения номеров". Цель обсуждения была крайне прагматичная - закрыть дефект, устранить его. В ходе обсуждения со стороны участников были попытки переключить внимание на другой системный уровень - принятый общий формат хранения номеров.
Стоп. Является ли "Маска в поле ввода Х" частью системы "Общепринятый формат хранения номеров". Давайте поразмыслим. Составим цепочку системного разбиения вверх от "Маска в поле ввода". Некоторые слова будут непонятны, они специфичны для конкретно моей системы. Пояснять не буду, не цель статьи, пониманию статьи не мешает.
Маска в поле ввода -> Поле ввода -> Форма добавления объекта Запрос -> Настройка объекта Запрос -> Вся метаинформация (настройка) стенда.
К системе "Общепринятый формат хранения номеров" мы не пришли. Да и на самом деле "Общепринятый формат хранения номеров" - не система. Это некая договоренность, некое бизнес-правило. Но эта договоренность выражается тем, что бОльшая часть номеров телефонов в системе хранится в определенном формате. Таким образом можно построить такую цепочку:
Маска в поле ввода, как правило хранения номера телефона в этом поле ввода в определенном формате -> Все правила хранения номеров телефонов в определенных форматах.
"Все правила хранения номеров телефонов в определенных форматах" уже является системой. Докажем это приведением критериев и ответом на критерий (критерии взяты из первого раздела книги):
- Физичность. Существование, т.е. занимание некоторого объема пространства-времени.
Система физична, выражается она во всех реализованных кодом и работающих в приложении ограничениях на формат ввода номера телефона. - Функциональность. Система должна выполнять какую-то функцию.
Система выполняет функцию по ограничению на количество и тип символов в некоторых полях ввода. - Наличие заинтересованного лица. Если "система" никому не нужна, то это не система.
У системы есть заинтересованные лица - в данном случае и проекте это департамент абонентского обслуживания. Их интерес - формат номера телефона. Предпочтение - единый формат. Обоснование - нормализованные номера можно использовать в автоматизациях, в отличии от ненормализованных. - Делимость на части. Система должна состоять из подсистем. Ее можно разделить на части.
Части системы - конкретные маски/правила в конкретных полях работающей системы (ПО). - Надсистема. У системы должна быть надсистема. Т.е. она должна являться частью какой-либо системы.
Вот тут чуть посложнее. Мы решили, что физичность системы "Все правила хранения номеров телефонов в определенных форматах" выражается в работающем коде-ограничениях на ввод номера телефона в полях приложения. Т.е. это просто часть исполняемого кода. Тогда надсистема, наверное, - весь исполняемый код.
Таким образом, доказали, что маску в поле ввода можно рассматривать как часть общепринятого формата хранения номеров.
Ну а обсуждение закончилось тем, что там вообще никакая маска не нужна)
P.S. Буду рад обратной связи по данной цепочке рассуждений, т.к. нет уверенности, что не совершил ошибок.
Софт есть описание
Лично для меня стало некоторым инсайтом, что софт сам по себе является описанием, является моделью какой-то части мира. Да, у софта, как у любой системы есть описание и документация - его исходный код в файлах. Но при этом когда софт работает на машине, он сам тоже является описанием!
Это понимание добавляет еще один хороший вопрос в список вопросов при проектировании софта, а именно: "Какую часть физического мира мы моделируем и зачем?"
Способ поиска целевой системы для софта
Про целевые системы будет идти речь в следующих главах книги, но во втором разделе был полезный практический совет по поиску целевой системы для софта.
Необходимо посмотреть на базу данных, с которой работает софт. На названия таблиц. Это позволит понять, какая часть физического мира отмоделирована. Например, если есть такие таблицы как "Клиент", "Договор", "Взаимодействие" и т.д., то, вероятно, перед нами CRM и целевая система - система управления взаимоотношениями с клиентом. Не просто CRM, а CRM + люди + прочие инструменты, которые позволяют этим людям взаимодействовать с клиентами.
Если есть такие таблицы как, "Заявка на обслуживание", "Инцидент", "Правило расчета SLA", "Команда (и связи с заявками как "Ответственная команда")", то перед нами service desk и мы моделируем процессы приема заявка, диспетчеризации, их выполнения и т.д.