Определение необходимой функциональности системы

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

Требования к функциональности имеют два источника, а именно жалобы имеющихся клиентов и системы конкурентов. К сожалению, оба эти источника сомнительны.

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

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

Современная наука выдвинула два основных способа определения функциональности, а именно анализ целей и анализ действий пользователей. Эти способы фактически не конфликтуют друг с другом, более того, в процессе определения функциональности желательно использовать оба.

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

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

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

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

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