§4.02 Описание системы (ментальное пространство)
Время: 60 мин чтение + 40 мин = 100 мин Что узнаешь: почему ментальная модель системы — это не сама система и не документ о ней, и как понимание этого различия устраняет большинство конфликтов в командах, работающих с одной системой
В одном предложении: описание системы — это ментальная модель, которая существует в голове наблюдателя, а не в физическом мире; одна система порождает столько описаний, сколько у неё наблюдателей, и это нормально, а не ошибка.
Сигнатура понятий:
- Описание системы — это ментальное представление системы, существующее в голове наблюдателя; отвечает на вопрос «как я понимаю эту систему?» и зависит от позиции, знаний и цели наблюдателя
Мем, который снимается. «Есть правильное описание системы - нужно только его найти.» На самом деле одна и та же система неизбежно описывается по-разному разными людьми, и это не проблема, которую нужно устранить. Менеджер по продажам видит CRM-систему как инструмент фиксации сделок. Разработчик видит её как набор сущностей в базе данных. Руководитель отдела видит как панель мониторинга активности команды. Все три описания правильные, каждое полезно для соответствующей роли. Конфликт возникает не из-за того, что одно описание неверное, а из-за того, что участники не понимают: они описывают одну систему с разных позиций.
Определение из источника.
В Pack (PD.FORM.027) описание системы определено как ментальное представление системы, модель в голове наблюдателя. Описание не существует физически: его нельзя взвесить или сфотографировать. Оно существует только в сознании конкретного человека.
Принципиальное свойство описания: оно неполно. Любое описание выделяет одни аспекты и игнорирует другие — это не дефект, а необходимое условие работы мышления. Описание, претендующее на полноту, стало бы таким же сложным, как сам объект, и потеряло бы ценность как инструмент мышления.
Описание зависит от наблюдателя: его знаний, цели, позиции. Поэтому у одной системы легитимно существует множество описаний, и задача системного мышления не в том, чтобы выбрать «правильное», а в том, чтобы понять, для какой цели какое описание полезно.
Развитие мысли.
Описание - самый невидимый уровень тройного различения, потому что оно существует только в голове. Это делает его одновременно самым гибким (можно быстро изменить модель, не трогая воплощение) и самым опасным (легко принять своё описание за саму систему).
Ключевая ловушка называется «смешение уровней»: человек работает со своим описанием системы, думая, что работает с самой системой. Инженер, прочитавший устаревшую схему, строит в голове описание, не совпадающее с воплощением. Когда он начинает действовать на основе этого описания, он получает неожиданные результаты: реальная система ведёт себя не так, как описание.
Описания в команде конкурируют, если их не синхронизировать. Один участник думает, что «система онбординга» начинается с первого письма новому сотруднику, другой - с момента подписания оффера. Оба используют один термин, но их ментальные модели описывают разные объекты с разными границами. Конфликт разрешается не «кто прав», а явным согласованием: «Какое описание мы принимаем за рабочее для нашей задачи?»
Для созидателя описание собственной системы развития — это ответ на вопрос «как ты понимаешь свой IWE?». У новичка описание простое и приблизительное. У опытного оно точнее, многоуровневее, связаннее с другими системами. Развитие описания — это развитие мышления. IWE помогает фиксировать описания, чтобы их можно было пересматривать и уточнять.
Метод - минимальный шаг. Практика «Два описания» (40 мин):
- Выберите систему, с которой вы работаете вместе с кем-то ещё: командный процесс, продукт, инструмент (5 мин).
- Запишите своё описание этой системы: как вы её понимаете, где её граница, что она делает, из чего состоит (10 мин).
- Попросите коллегу сделать то же самое независимо или сами попробуйте написать, как, по-вашему, описывает систему коллега (10 мин).
- Сравните два описания: в чём они совпадают? В чём расходятся? Какое расхождение важнее всего для вашей совместной работы? (15 мин).
Пример из жизни. Виктор - руководитель проекта, Ольга - тестировщик. Они оба работают с «системой контроля качества» в их компании. Виктор описывает её как набор метрик и дашбордов. Ольга - как набор тест-кейсов и процедур. Оба правы со своей позиции. Но когда возник вопрос «нужно ли нам обновить систему?», они пришли к разным выводам: Виктор считал, что нужно добавить новые метрики, Ольга - что нужно пересмотреть тест-кейсы. Конфликт не решился бы спором, только явным выяснением: что каждый из них понимает под «системой контроля качества» и для какой задачи это описание полезно. Когда они это сделали, оказалось, что оба правы и обе задачи нужны, но для разных целей.
Типичная ошибка. «Моё описание точнее, потому что я дольше работаю с этой системой.» Опыт улучшает описание, но не делает его единственно верным. Человек, долго работающий с системой, рискует накопить «описание по привычке» - модель, которая соответствует тому, как система работала раньше, а не сейчас. Новый взгляд иногда точнее именно потому, что не загружен устаревшими представлениями.
Вторая ошибка: считать, что описание избыточно, - «мы и так понимаем, как работает система». Это суждение само является описанием, неявным. Неявное описание особенно опасно: оно невидимо, поэтому его сложно проверить и скорректировать. Явная формулировка описания - не бюрократия, а инструмент синхронизации.
Степени мастерства:
| Степень | Что происходит | Критерий перехода | |---------|----------------|-------------------| | 1. Объясняю | Могу объяснить, что описание системы — это ментальная модель в голове, а не сама система | Один раз выполнил практику «Два описания» | | 2. Умею | Могу в командной дискуссии выявить расхождение описаний и назвать его явно | Есть запись: система + два описания + ключевое расхождение | | 3. Навык | Автоматически замечаю, когда конфликт в команде — это конфликт описаний, а не фактов | Регулярность: в спорных ситуациях уточняю описание прежде, чем спорить о решении | | 4. Мастерство | Помогаю командам согласовать описание системы, когда расхождение описаний блокирует работу | Есть кейс, где явное согласование описаний разрешило хронический конфликт |
Проверка себя.
- Понимание: вы можете объяснить, почему два человека с разными описаниями одной системы оба могут быть правы.
- Поведение: когда в обсуждении возникает конфликт, вы проверяете, не является ли он конфликтом разных описаний одной системы, а не конфликтом фактов.
- Застревание: если вы уверены, что ваше описание системы единственно верное, вы смешиваете описание с самой системой. Проверьте: «Как бы эту систему описал кто-то с другой ролью?»
Что дальше. Описание существует в голове и не может быть напрямую передано другому человеку. Для передачи описаний люди создают документацию - физические артефакты, в которых записаны описания. Следующий подраздел - о документации системы: что это такое и чем она отличается от описания.