Чему аналитики могут научиться у сценаристов и режиссеров.
В комментарии к посту про Playscript Алина Миронова пишет, как ей помогает в системном анализе образование и паттерны мышления сценариста игрового кино:
1. Переход между крупным планом и общим, навык мысленного приближения и отдаления.
2. С одной стороны, не должно быть ничего лишнего, с другой — нужно подвесить чеховское ружье, которое сработает потом.
3. Описание только действий и реакций (пользователь не может догадаться о внутреннем состоянии системы, он может только увидеть что-то).
4. Думать о том, кто это будет читать.
5. Навык придумывания концовок и альтернатив.
Я бы к этому добавил несколько идей, которые я почерпнул, в основном, в канале знакомого сценариста. Они применимы к системному анализу, а точнее — к форме представления результатов, т.к. это тоже литература — не художественная, техническая, - но есть и общие литературные приёмы, обусловленные хотя бы способом восприятия текста - протяженном во времени. Текст не загружается в голову целиком, текст воспринимается читателем в течение времени, и этим восприятием можно (и нужно!) управлять. И вот какие тут есть аспекты:
👀 Чьими глазами мы смотрим в данный момент? Вот этот текст, он с чьей точки зрения написан? С точки зрения пользователя? Или с точки зрения программиста системы? Или с точки зрения DevSecOps инженера? Нельзя в одном описании перескакивать с одной точки зрения на другую. Вообще, у нас про точки зрения целый стандарт есть: ISO 42010 или ГОСТ Р 57100 "Systems and software engineering. Architecture description".
🥸 Кто в какой момент что знает? У сценария это называется "драматическая структура", у проектного документа — просто структура. Есть три лица: автор, пользователь системы и читатель документа. Информация между ними распределена неравномерно: автор знает о системе и её сценариях почти всё, пользователь — только то, что может понять из взаимодействия с системой, читатель — то, что успел узнать из текста. Соотношение этих знаний определяет структуру истории, но и для технических документов было бы неплохо помнить — что мы уже рассказали читателю, а что ещё нет; что уже знает пользователь на каком-то экране, а что от него скрыто.
🏁 Когда заканчивается сцена? Это в проектировании применимо для пользовательских сценариев и бизнес-процессов. Ответ сценариста: сцена заканчивается, когда один из участников достигает своей мини-цели. У каждого участника сценария есть своя мини-цель, если участников много - из этих целей рождается мини-конфликт. Как только цель достигнута, персонажу больше нечего в ней делать — сцена закончилась. Это первый уровень. Второй — сцена заканчивается, когда в ней произошло то, что нужно вам, как проектировщику системы. А вам, как правило, нужно либо подготовить материал для дальнейшего развития сюжета, либо чтобы пользователь что-то понял и, например, приобрел мотив к дальнейшим действиям.
⚔️ Про конфликты и связи между участниками. В составе ролей пользователей (исполнителей процессов, стейкхолдеров — особенно стейкхолдеров!) не должно быть лишних людей. Все должны быть связаны друг с другом через конфликт или через поддержку/заботу. При этом, если мы смотрим с точки зрения главного героя — у него есть те, кто "выше"-главнее, кто его контролирует, кому он отчитывается, и те, кто "ниже": о ком он заботится, кому ставит задачи и т.п. Все должны быть свзязаны со всеми. Помним, что система только лишь отражает взаимодействия между людьми, системы нет — а конфликты и отношения всё равно есть. Хорошо бы их зафиксировать в явном виде, осознанно. (Ещё есть версия, что основные линии конфликта должны составлять треугольник — это верно для драматургии, уж не знаю, насколько это применимо к системному анализу).
♾ Проектирование от конца к началу. Сначала сформулируйте желаемый результат операции. Её финал. К чему мы должны прийти в итоге? Сформулируйте это состояние. Потом начинайте распутывать по шагам от конца к началу — а что было было перед этим? А за шаг до этого? Кто что должен был сделать? Когда понятная цель, проще становится привести к ней всех участников.
В комментарии к посту про Playscript Алина Миронова пишет, как ей помогает в системном анализе образование и паттерны мышления сценариста игрового кино:
1. Переход между крупным планом и общим, навык мысленного приближения и отдаления.
2. С одной стороны, не должно быть ничего лишнего, с другой — нужно подвесить чеховское ружье, которое сработает потом.
3. Описание только действий и реакций (пользователь не может догадаться о внутреннем состоянии системы, он может только увидеть что-то).
4. Думать о том, кто это будет читать.
5. Навык придумывания концовок и альтернатив.
Я бы к этому добавил несколько идей, которые я почерпнул, в основном, в канале знакомого сценариста. Они применимы к системному анализу, а точнее — к форме представления результатов, т.к. это тоже литература — не художественная, техническая, - но есть и общие литературные приёмы, обусловленные хотя бы способом восприятия текста - протяженном во времени. Текст не загружается в голову целиком, текст воспринимается читателем в течение времени, и этим восприятием можно (и нужно!) управлять. И вот какие тут есть аспекты:
🏁 Когда заканчивается сцена? Это в проектировании применимо для пользовательских сценариев и бизнес-процессов. Ответ сценариста: сцена заканчивается, когда один из участников достигает своей мини-цели. У каждого участника сценария есть своя мини-цель, если участников много - из этих целей рождается мини-конфликт. Как только цель достигнута, персонажу больше нечего в ней делать — сцена закончилась. Это первый уровень. Второй — сцена заканчивается, когда в ней произошло то, что нужно вам, как проектировщику системы. А вам, как правило, нужно либо подготовить материал для дальнейшего развития сюжета, либо чтобы пользователь что-то понял и, например, приобрел мотив к дальнейшим действиям.
⚔️ Про конфликты и связи между участниками. В составе ролей пользователей (исполнителей процессов, стейкхолдеров — особенно стейкхолдеров!) не должно быть лишних людей. Все должны быть связаны друг с другом через конфликт или через поддержку/заботу. При этом, если мы смотрим с точки зрения главного героя — у него есть те, кто "выше"-главнее, кто его контролирует, кому он отчитывается, и те, кто "ниже": о ком он заботится, кому ставит задачи и т.п. Все должны быть свзязаны со всеми. Помним, что система только лишь отражает взаимодействия между людьми, системы нет — а конфликты и отношения всё равно есть. Хорошо бы их зафиксировать в явном виде, осознанно. (Ещё есть версия, что основные линии конфликта должны составлять треугольник — это верно для драматургии, уж не знаю, насколько это применимо к системному анализу).
♾ Проектирование от конца к началу. Сначала сформулируйте желаемый результат операции. Её финал. К чему мы должны прийти в итоге? Сформулируйте это состояние. Потом начинайте распутывать по шагам от конца к началу — а что было было перед этим? А за шаг до этого? Кто что должен был сделать? Когда понятная цель, проще становится привести к ней всех участников.