Принцип информационной открытости (И). Для существования и нормальной работы проективной системы очень важно, чтобы пользователь мог узнать все о работе любой ее части. Всякий инструмент должен быть документирован до степени, достаточной для понимания принципов его работы и всестороннего использования. В документацию нужно включать не только сведения о том, как этот инструмент применять, но и описание того, что именно и как именно он делает. Только такое знание позволит настроить его на решение конкретной задачи совместно с другими инструментами. Более того, если пользователь изготовил решение некоторого класса задач и не снабдил его полной документацией, это решение бесполезно для системы (пускай даже оно крайне полезно пользователю). Предпочтительнее менее мощный инструмент, но такой, которым в аналогичном случае сможет воспользоваться любой читатель документации. Более того, понимая устройство такого инструмента, другой пользователь сможет слегка улучшить его, приспособив к своему варианту задачи. Если инструмент удобен и понятен, так будут поступать многие, и довольно скоро он превзойдет по мощности и гибкости любой информационно закрытый программный продукт, для развития которого есть только один стимул: найти средства и заплатить разработчику.
Таким образом, информационно открытая система отлично приспособлена для разработки и эксплуатации "в сообществе" (community), то есть в ситуации, когда использовать, исправлять и развивать систему может, с формальной точки зрения, любой желающий, а на самом деле - именно тот, кому она нужна и кому это интересно (в случае информационной закрытости круг пользователей и разработчиков ограничивается "допущенными" до документации, причем, как правило, не разбираясь, интересно им это или нет). Еще одно достоинство информационно открытой системы заключается в том, что это единственная комфортная среда для любознательного человека. На любой вопрос он, если потребуется, может найти ответ. Такое положение дел позволяет непрерывно совершенствовать профессиональный уровень, оставляя себе наибольшую степень свободы. Любая задача представляется разрешимой, стоит только основательно изучить соответствующие инструменты (возможно, доработать их, или даже изобрести новые) и хорошенько подумать.
Принцип минимизации затрат (З). Из старой сказки: "Что быстрее всего? Мысль". Из новой: "Человек не должен работать. Работать должна машина, а человек - думать". Чего не умеет и никогда не сумеет машина? Мыслить. Что машина умеет лучше всего? Точно следовать указаниям. Поэтому в человеко-машинной системе мыслительные функции (вроде решения задач) стоит отдать человеку, а автоматические (вроде повторения действий) - машине. Более того, если человеко-машинная система вообще нуждается в человеке, то именно потому, что перед ней возникает известное число мыслительных задач, требующих решения. Ежели таковые имеются, все равно нужен кто-то, кто подтвердил бы их правильность. Значит, в хорошей проективной системе человек в основном должен решать мыслительные задачи (придумывать и составлять проект), а механических, бездумных действий совершать как можно меньше. Обдуманные действия сопровождаются, как правило, определенным внутренним усилием, которого требует принятие на себя ответственности за их результат.
Если, например, необходимо переименовать 20 файлов, то правильным решением будет составить одну команду - параметрический цикл, в котором новое имя каждого файла будет вычисляться из старого. Вводить же все 20 команд вручную не следует: нет гарантии, что где-нибудь на 17-й пользователь не ошибется при наборе. Чем меньше ручной работы, тем меньше вероятность механической ошибки. Взамен от человека требуется умение слегка программировать и некая решимость написанную микропрограмму счесть правильной, потому что цена ошибки возросла в 20 раз: если ошибиться, то будут неправильно переименовываться все файлы. При этом затраты (в основном умственные) на разработку решения могут быть весьма высоки (пришлось учиться программировать), затраты на реализацию должны быть сведены до минимума (цикл с одной параметризованной командой записывается явно короче 20 простых), а затрат на выполнение - никаких.
Заметим: затраты на повторную реализацию будут существенно меньше. Если будущая задача станет похожа на уже решенную, достаточно только подправить проект. Если это будет та же самая задача, главное - оформить решение так, чтобы потом вспомнить, что это именно оно, и чтобы им могли воспользоваться другие (см. И).
Принцип умопостижимости контекста (У). Для того чтобы задача могла быть решена, необходимо создать пользователю условия, в которых ее удобно решать. В частности, когда идет поиск решения и встает вопрос о выборе инструмента, очень важно отбросить как можно больше ненужных возможностей системы. Необходимо сократить контекст поиска до объема, который пользователь может целиком удерживать в голове. Доказано, что для этого в области выбора должно быть не более семи (максимум - девяти) однотипных частей (назовем это "правилом 7+-2", см. [32]). Поэтому инструментальная область должна поддаваться членению как раз на такие семь функционально различных частей, в каждой из которых тоже имеет смысл проводить семичастное деление, и т. д. вплоть до атомарных действий.
Учитывая, что уровней у такой пирамиды должно быть тоже не больше семи, получаем по меньшей мере 77=823 543 элемента в ее основании. Вполне достаточно... для идеальной системы. К сожалению, такой на свете нет. Однако и неидеальную систему следует разрабатывать с учетом ограниченных возможностей человеческой памяти и восприятия.
Другая сторона принципа умопостижимости контекста: даже самый сложный проект должен быть в целом понятен пользователю. Это можно назвать требованием human readable: любой проект должен быть таким, чтобы пользователь мог прочесть его и (после изучения документации) понять целиком. К примеру, программа, состоящая из двух функций по пять тысяч строк в каждой, представляет собой совершенно не читаемый проект (если только в ней не предусмотрен какой-то не относящийся к языку программирования способ разбиения на уровни).
Более строгое требование к проекту таково: достаточно опытный пользователь должен быть в силах не только просчитать, но и написать с нуля сложный проект (т. е. быть human writeable). Вообще-то с нуля никто сложные проекты не пишет, всегда найдутся какие-то предварительные заготовки, части старых решений и т. п. Но требование это гарантирует, что в проект не надо будет вставлять избыточную или не имеющую отношения к делу информацию. Так, модный нынче язык моделирования чего угодно XML не отвечает требованию human writeable, потому что содержит множество синтаксического шума: диаграмма из прямоугольника, эллипса и кривой Безье со стрелкой на конце в формате утилиты xfig занимает 356 байт и может считаться пригодной для чтения и записи вручную (правда, после преобразования некоторых числовых параметров в строковые), а вот аналогичная диаграмма, изготовленная при помощи утилиты dia, представляет собой 4,7 Кбайт на XML (стоит отметить, что ни тот, ни другой файл, строго говоря, не являются проектами, потому что и dia, и xfig суть визуальные средства разработки).
Принцип персональной ответственности (О). Уже не раз упоминалось, что пользователь проективной системы берет на себя ответственность за качество проекта, а стало быть, и за поведение системы, собранной на основе этого проекта, и за качество получаемого продукта. Деваться ему некуда: всякий раз, создавая решение даже самой немудреной задачи, перед тем как пустить его в ход, он должен сказать самому себе: "Да, это будет работать". То же самое он должен сказать своему начальнику и всем пользователям подвластной ему системы (если он системный администратор) или даже всей сети Internet. Самая элементарная команда работы с системой предполагает, что человек сначала подумал и принял решение. То, что команда может быть плодом невежества, безалаберности или глупости человека, в расчет не берется.
Столь трепетное и уважительное отношение к мнению человека выливается в достаточно суровое правило "захотел - получил": что бы ни творил пользователь, предполагается, что делает он это сознательно. Хочет удалить все свои файлы - что ж, значит, так надо (команда unix: rm -rf $HOME/*. ВНИМАНИЕ! Эта команда действительно сработает! Не повторять! И кстати сказать, она удаляет не все файлы, см. главу 7). Восстановить удаленные файлы нельзя: вы же их сами удалили. Или надо было воспользоваться каким-нибудь другим, безопасным способом: вместо того, чтобы удалять ненужные файлы, переместить их в специальный каталог. Если пользователь нажал одну клавишу в текстовом редакторе - это команда редактирования, а не случайность, текст меняется. В редакторе, как и в любом инструменте разработки, конечно, есть функция отмены последнего действия: человеку свойственно ошибаться. Однако человеку свойственно и обдумывать решения, поэтому достаточно предусмотреть отмену только последнего действия. Правило "захотел - получил" здорово дисциплинирует, хотя на первых порах выглядит жестоко.
Второе правило: ответственность обусловлена знаниями. Хорошая проективная человеко-машинная система устроена так, что чем больше существует областей, в которых компетентен человек, тем больше он имеет возможностей изменять поведение системы, тем полнее управляет машиной. Пока вы не изучите основные принципы работы, скажем, процедур резервного копирования системных дисков, вы не сможете применять их. Или не станете, опасаясь взять на себя пока непосильную ответственность (за испорченную файловую систему). И наоборот, если человек знает, как улучшить работу системы, эти знания надо использовать. Если в придуманном решении есть доля творческого наития, вполне возможно, что никто другой так с этой задачей не справится.