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

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

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

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

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

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

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

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