Когнитивные паттерны аналитика.
В обсуждениях поста про темы докладов возник очень классный запрос на обзор когнитивных стратегий системного аналитика.
Как думают экспертные и опытные системные аналитики? Про что они думают? Что важно в ходе их мыслей?
Тема интересная, и требует рефлексии - не всегда эксперт сам понимает, как он думает 🤷🏼♂️
В целом за стратегию не скажу, но вот отдельные паттерны, которые бывают полезными (без какой-либо последовательности, скорее для проверки):
👁 Умение видеть абстракции и переключаться между ними. То есть, когда мы говорим или читаем про какой-то объект/явление, мы должны понимать — на каком уровне этот объект находится. Это уровень бизнеса? Или уровень действий пользователя? Или уровень интерфейса системы? Устройства системы? (И все уровни внутри архитектуры). Переключаться — это видеть связи и понимать, как объект на одном уровне соответствует уровню на другом. И как может быть по-другому. Тут же — понимание связи и умение различать функцию и конструкцию. Вот есть кнопка. Это часть конструкции. Какую функцию она выполняет? Показывает следующую страницу выдачи найденных товаров. Можно ли для той же функции использовать другую конструкцию? Можно, например — показывая следующую страницу по долистыванию до низа страницы. Это, кстати, так же разница между действием (по смыслу) и интерфейсом (по виду элемента управления для этого действия).
Идём вниз по уровню абстракции — как реализовано действие по этой кнопке? Как это разложено в слоях архитектуры системы: на фронте, в методах API, в контроллере, в уровне доступа к данным. Идём вверх — какие действия пользователь тут выполняет? Зачем ему вообще постраничный вывод, что он хочет увидеть? Для чего он это делает, в рамках какой деятельности? В чём его цель?
⚛️ Машинка типов. Мы смотрим на объект, какого он типа? Какие объекты одного типа с ним? Какие отличаются? Какие есть производные типы? Какие есть обобщающие понятия (супертипы)? Тут мы можем ответить на известный вопрос, как сложить яблоки с грушами. Да очень просто, 2 яблока + 3 груши = 5 фруктов. Что объединяет договор, счёт и акт? Они все — документы, у каждого есть номер, дата, подпись. С документом любого вида можно обращаться одинаково, но у каждого конкретного вида есть свои специфические поля и варианты действий (счет можно оплатить, а договор - расторгнуть).
🎭 Выявление омонимов: называется одинаково, а смысл (и тип!) разный. Вот тут "пользователь" — это объект в системе, "карточка пользователя", на самом деле, или действующее лицо, актор, который в системе не учтен?
📈 Разница между структурой данных и их представлением. Мы видим какой-то объект, содержащий данные. Это самостоятельный объект, или это просто форма представления данных каких-то объектов? Выписка, отчёт, витрина?..
💬 Выявление общих и конкретных слов. Тут просто: если можем вставить слово "какой-то" и это нормально звучит — значит, слишком общее слово, нужно конкретизировать.
🔬 Внимание к определениям. Что означает это слово? Оно имеет общее, единым образом понимаемое значение? Или оно в данной предметной области означает что-то специальное? Вводилось ли это слово ранее, или оно встретилось впервые?
📁 Группировка и разделение данных/функций по принципу единой ответственности. То, что в микросервисах называется "low coupling, high cohesion", а в ООП — SRP. Тут может быть и протечка абстракций (в одном классе и хранение данных и представление), и смешение бизнес-логики (в одном классе и список студентов, и их оценки по предметам).
🧬 Учет кратности связей: что с чем сколько раз связано? Что у кого сколько раз может быть? В сколько групп может быть зачислен студент? Сколько студентов может быть в группе? Сколько оценок может быть у студента по одному предмету? Скольким студентам может быть выставлена оценка?
🎩 Умение принимать разные роли и смотреть с разных позиций (на систему). А теперь смотрим с точки зрения архитектора. А теперь — с точки зрения пользователя. А теперь — с точки зрения офицера безопасности. И т.д.
В обсуждениях поста про темы докладов возник очень классный запрос на обзор когнитивных стратегий системного аналитика.
Как думают экспертные и опытные системные аналитики? Про что они думают? Что важно в ходе их мыслей?
Тема интересная, и требует рефлексии - не всегда эксперт сам понимает, как он думает 🤷🏼♂️
В целом за стратегию не скажу, но вот отдельные паттерны, которые бывают полезными (без какой-либо последовательности, скорее для проверки):
Идём вниз по уровню абстракции — как реализовано действие по этой кнопке? Как это разложено в слоях архитектуры системы: на фронте, в методах API, в контроллере, в уровне доступа к данным. Идём вверх — какие действия пользователь тут выполняет? Зачем ему вообще постраничный вывод, что он хочет увидеть? Для чего он это делает, в рамках какой деятельности? В чём его цель?