Пользователь как клиент

Первый, наиболее очевидный путь "сближения" или «дружбы» человека и машины состоит в том, чтобы машина была бы как можно проще. Несмотря на сложность системы и разнообразие решаемых ею задач, вполне возможно оставить для взаимодействия с человеком только те управляющие возможности, что лежат в прикладной области. Иными словами, человеку будет доступно (и известно) лишь то, что относится к постановке и решению задачи. При этом инструментальную область - все, что относится к устройству системы и управляет ходом решения, - следует оставить доступной только разработчикам и экспертам, а от конечного пользователя скрыть.

Кем себя будет ощущать пользователь такой системы? Заказчиком и одновременно потребителем, то есть клиентом: он описывает на доступном ему языке продукт, который хочет получить, и отдает это описание на отработку машине. Когда работа машины окончена, то, что получилось, немедленно идет в дело. Предполагается, что некоторые параметры продукта (а иногда и все) машина будет узнавать уже по ходу работы, задавая наводящие вопросы, опять-таки на доступном клиенту языке. Другой вариант - держать перед глазами клиента некую модель требуемого объекта, которая изменялась бы всякий раз, когда изменяется сам объект. Это называется WYSIWYG, What You See Is What You Get ("что видишь, то и получишь"). В этом случае можно не вводить вообще никакого промежуточного языка, оставив клиенту только те действия, смысл которых понятен из изменений модели.

В чем будет заключаться участие человека в такой системе? По большей части в точном следовании "инструкциям по применению". А как иначе: система сложна, ее поведение непредсказуемо (оттого, что непонятно ее устройство), и, если по незнанию нажать какую-нибудь не ту кнопку, результат может оказаться плачевным. Поскольку действия человека в таких системах сводятся к выполнению неких процедур, то такие системы можно назвать процедурными.

Уровень знаний о системе в этом случае может быть минимальным (как включить, как заставить решать задачу и т. п.). Более того, знание устройства системы, понимание принципов ее работы помогут пользователю лишь в малой степени, потому что возможности изменить эти принципы у него нет (иначе она давно бы уже вышла из строя из-за неумелого руководства). Что следует знать досконально, так это то, какие именно действия над объектом будут выполнены, если потянуть за тот или иной рычаг управления.

Кто оказывается главным в такой системе, от кого зависит качество получаемого продукта? Ответ: создатели системы, заложившие в нее соответствия между рычагами управления и выполняемыми действиями. Если после нажатия очередной кнопки объект, вопреки сказанному в инструкции, испортился - это недоработка авторов, а не ошибка клиента: все, что он мог сделать, - это только не нажимать на кнопку. Клиент такой системы требует гарантий качества от разработчиков, потому что сам в силах гарантировать только неукоснительное следование инструкциям и не более того.

Пользователь как администратор

Второй путь сближения машины и человека - сделать сложную машину удобной для освоения и понимания. В идеале инструментальная область должна быть так же понятна и близка пользователю, как и прикладная. Разработчикам предстоит потратить немало усилий на выработку внутренней структуры системы, на полное ее описание, придется предусматривать ограничения в использовании инструментария в зависимости от уровня компетенции работающего с системой человека (то есть, как минимум, обеспечить "защиту от дурака") и т. д. Пользователь такой системы обязан знать основы ее устройства и весь инструментарий, при помощи которого он может конструировать решения задач. Причем чем больше он знает, тем более качественными получаются решения. Пользователь фактически управляет работой системы, то есть выступает в роли управляющего или администратора.

Администратор человеко-машинной системы и "системный администратор" не одно и то же. Это может быть программист или оператор СУБД. Администратор - это производитель системного продукта, или тот, кто выполняет (причем, часто для других, а не для себя) работу при помощи машины.

Такой подход требует, чтобы в системе были предусмотрены средства создания решений любых возможных задач. Для компьютера это высокоуровневые языки программирования и отдельные программы для элементарных взаимодействий с системой. Конечно, необходимо, чтобы и пользователь свободно владел этими средствами. Решив (чаще всего чисто умозрительно) поставленную задачу, администратор дает команду машине: "Делай по моему проекту". Машина работает, а пользователь занимается другими делами, не забывая, однако, приглядывать за системой: хорошо ли справляется с задачей его творение, не стоит ли где подправить? Возможность самому пользователю составлять проект решения задачи - это основная особенность целого класса систем, которые называются проективными.

В таких системах, чем больше администратор знает, тем лучше она работает. Кроме того, больше должно быть именно знаний, то есть понимания внутрисистемных механизмов, а не просто сведений о том, как в разных случаях пользоваться системой. К тому же администратор должен иметь ясное представление обо всех прикладных областях системы. Получается, что строже всего разработчикам такой системы надо следить за объемом данных, достаточных для решения конкретной задачи. Когда количество рычагов управления системой перевалит за определенный предел, то обычный человек управлять такой системой уже не сможет. Если объем знаний не чрезмерно большой, а все-таки доступен для человека-администратора, то само администрирование становится доступно любому, кому не лень напрягать мозги.

В проективной системе как раз администратор дает гарантии качества получающегося продукта - в меру своей квалификации, конечно. Претензии к разработчикам возникают только тогда, когда очевидна неисправность инструмента (но ее, как правило, все равно можно обойти при помощи другого инструмента). Так или иначе, в такой человеко-машинной системе больший авторитет имеет человек.

* Можно привести такой образный пример: «насколько бы качественна ни была дрель, ею можно и починить рояль, и испортить его, - все зависит от того, где и сколько сверлить».

Прежде чем выяснять основные принципы устройства процедурных и проективных систем, отметим парадокс, связанный с тем, насколько человек свободен во время работы с машиной. Не желая попасть в зависимость от машины, многие выбирают работу в качестве клиента процедурной системы. Под процедурную систему не нужно "подстраиваться": постигать ее структуру, учить "машинный язык", настраивать ее. Наоборот, сама система всячески демонстрирует, как она подстраивается под желания пользователя, даже предугадывает их. В результате почти все время работы в такой системе он проводит, выполняя ее команды типа "для продолжения нажмите кнопку далее" или "выберите тип преобразования файла", то есть попадает в ситуацию, когда для эффективного решения своих задач ему приходится временно жертвовать собственной свободой.

В то же время другой пользователь, потративший время на изучение подходящего инструментария в проективной системе, изобретает решения все более сложных задач, притом всю неинтересную, механическую работу делает за него машина. Изучая инструмент и дополняя его по своему усмотрению, он обретает свободу в системе, а не жертвует ею. Может быть, именно в том, что за последние два десятилетия процедурные системы распространились так широко, и кроется причина машинобоязни?