Недавно провёл две лекции для школьников — 9–11 классы.
И я сознательно не рассказывал им про UML, архитектуру и “как правильно строить системы”.
Потому что это не работает.
Вместо этого мы разбирали простые вещи из их жизни:
— турникет в школе
— электронный дневник
И смотрели на них с одной позиции:
не «как должно работать», а
«что будет, если что-то пойдёт не так»
И именно на этом моменте у них включалось внимание.
Турникет: простая штука, пока не начинаешь думать
Начинаем с базового сценария:
ученик прикладывает карту → проходит в школу.
Всё.
Кажется, что система элементарная.
Но дальше я задаю вопрос:
— а что, если ученик забыл карту?
Окей, допустим, его пропускает охранник.
Следующий вопрос:
— а если карта потеряна или украдена?
Нужно блокировать.
А как быстро?
А кто это делает?
Дальше:
— а если ученик передал карту другу?
Система этого не видит.
Значит, либо принимаем риск, либо придумываем дополнительные проверки.
И понеслось.
Где система начинает «расползаться»
Через 5–10 минут обсуждения появляется куча сценариев:
— опоздание: пускать или нет
— учителя: у них тот же проход или другой
— родители: могут ли заходить
— пожар: турникет должен открыться автоматически
— отключили электричество: что происходит
— турникет сломался: как люди заходят
— нужно ли хранить историю проходов
— кто имеет доступ к этим данным
И в этот момент происходит важная вещь.
Ребята начинают понимать:
турникет — это не железка
это набор правил
Электронный дневник: “просто оценка”
Дальше берём вторую систему.
Учитель ставит оценку.
Ученик её видит.
Максимально простая идея.
Но задаём один вопрос:
— а можно ли изменить оценку?
Если да — кто может?
Учитель?
Администратор?
Классный руководитель?
Ошибки, которые ломают систему
Дальше начинаем усложнять:
— учитель поставил оценку не тому ученику
— система зависла в момент сохранения
— оценка появилась дважды
— оценка изменилась “задним числом”
И сразу возникают вопросы:
— хранится ли история изменений
— видно ли, кто и когда поменял
— уведомляются ли родители
— когда оценка становится “финальной”
И тут становится очевидно:
оценка — это не цифра
это ответственность
Что на самом деле делает системный аналитик
В этот момент я обычно останавливаю обсуждение и формулирую простую мысль.
Системный аналитик почти никогда не думает:
“как должна работать система”
Он думает по-другому:
“где она сломается”
И дальше:
— какие сценарии мы забыли
— где пользователь сделает не так
— где система даст сбой
— где появится конфликт
Почему это важно
Потому что реальные проблемы в системах почти никогда не возникают в “основном сценарии”.
Они возникают:
— на исключениях
— на ошибках
— на нестандартных ситуациях
И если их не продумать заранее — система начинает вести себя непредсказуемо.
Вывод
Любая “простая” система перестаёт быть простой, как только в неё приходят:
— реальные пользователи
— ошибки
— ограничения
И именно с этого момента начинается работа аналитика.
Не в рисовании схем.
А в попытке заранее понять:
где всё пойдёт не так