Почему сайт — это не автоматизированная система

Начал отвечать на вопрос, заданный на форуме Сообщества аналитиков, и понял, что получилась целая небольшая статья.

Вопрос был задан как комментарий к моему заявлению:

— Мне категорически не нравится идея подводить однопользовательские приложения в веб под определение АС.

— А почему? Чем чревато?

Краткий ответ такой: чревато тем, что вместо сайта у вас получится АС, а пользователей к этому жизнь не готовила. :)

Более подробный ответ ниже.

По большому счёту, источники проблем можно найти в самом определении АС. Они могут показаться слишком размытыми, «философскими», но в них коренится принципиальное несоответствие подходов к созданию АС и сайтов, предоставляющих какие-то услуги массовому пользователю.

Автоматизированная система — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

Во-первых, посетителя сайта нельзя считать персоналом — составной частью АС. Он не винтик машины, обеспечивающий выполнение каких-то функций, а потребитель услуги. Это существенное отличие: действия персонала можно регламентировать, его можно и нужно обучать, для чего разрабатывается целый комплект документации. Ну и персонал, конечно, не платит за услугу эксплуатации АС — наоборот, платят обычно ему за то, что он с этой АС мучается.

Потребителя услуги регламентировать нельзя. Если продукт предназначен для решения сравнительно сложных специальных задач, можно дать ему рекомендации в виде руководства пользователя. Но не в том составе и не в тех форматах, которые предлагаются для АС. Иначе он проголосует ногами и деньгами за продукты конкурентов.

Во-вторых, АС изначально ориентирована на автоматизацию определённых функций. Просто исходя из этого определения, функциональные требования выходят на первый план, а нефункциональные рассматриваются как ограничения, которые накладываются и на разработку, и на способы эксплуатации.

В вебе то, что у аналитиков принято называть «нефункциональными требованиями», сейчас обычно является не ограничением, а конкурентным преимуществом.

Возьмём, например, личные планировщики дел. Их сейчас очень много, и набор функций у них примерно один и тот же. Пользователи выбирают их не столько по функциям, сколько по впечатлениям от продукта и трудно поддающимся определению «фишкам». Интуитивность интерфейса, прозрачная для пользователя защита данных, мультиплатформенность, интеграция с популярными сервисами и прочая, и прочая — это всё особенности, которые заставляют людей отдавать предпочтение определённым продуктам. А также довольно быстро их менять, переходя с одного сервиса на другой.

В какой-нибудь банковской системе (АБС), которая является типичным представителем класса АС, пользователи готовы десятилетиями мириться с неудобным и непонятным интерфейсом, не очень высокой производительностью на пользовательских задачах (какой-нибудь отчёт генерируется несколько минут), навязчивой системой безопасности — всё ради функциональности, без которой банк просто не сможет работать. Этим, кстати, объясняются кошмарные (с точки зрения обычного пользователя) UI абсолютного большинства банковских систем: функциональность всегда в приоритете, архитектуру поменять можно только путём разработки новой системы, а на всякие эти ваши юзабилити не остаётся ни времени, ни сил. А персонал можно и обучить, ему за это деньги платят.

В вебе такое отношение к пользователям не пройдёт. Ваш сервис умрёт, не родившись, если вы будете относиться к нему, как к АС, и применять к его разработке соответствующие подходы.