Во втором случае, если документ пишется по функциям, нужно определить, сколько в программе крупных компонентов, описание которых будет отдельными разделами, затем, в свою очередь, оценить количество элементов (функций программы), составляющих собой компонент (этим элементам в документации будут посвящены главы). После этого потребуется оценить объём и затраты времени на описание каждой функции, после чего можно оценивать общее время работы путём всё того же умножения количества разделов на среднее число глав в разделе на объём или время работы с одной главой (функцией).
В качестве примера можно привести стандартную строку меню: пункты здесь станут разделами, а конкретные функции в них — главами (или пунктами, можно назвать как угодно).
После получения времени и объёма основной части документа, нужно прикинуть, сколько места и времени будет занимать сопутствующая информация — установка программы, её настройка и т. д. В кейсоориентированном варианте все это попадёт в перечень кейсов и будет учтено автоматом, при описании по функциям же нужно уделить этому отдельное внимание.
Также стоит сделать одно существенное замечание: оценка объёма здесь приведена для документа в целом, а время — лишь для его набора на клавиатуре, без всей сопутствующей работы. Подробнее о том, как оценить полные временные затраты на документ, рассказывается в следующей главе.
Объём графики для пользовательской документации рассчитывается аналогичным образом, но с оглядкой, что её должно быть не слишком много, поясняющие скриншоты нужны только в самых сложных местах, так как вы делаете её для упрощения и наглядности в сложных моментах, а не «зарисовываете» каждый шаг (за исключением инструкций для домашних пользователей — там скриншотом снабжается каждое действие, не то что функция). Также одним скриншотом окна настроек можно заменить очень много текста — достаточно будет рассказать, что сделать в этом окне, без каких-либо текстовых пояснений того, какой флажок или опция в каком месте окна находятся.
Если оценивается объём графики для аналитики, то исходить надо из двух вариантов: график или диаграмма либо заменяют текст, давая пользователю информацию только в виде изображения, либо дополняют его. Как правило, оптимальный вариант — представить все динамично изменяющие данные в виде изображения, добавив после него текстовый анализ и выводы.
При разработке руководства администратора количество необходимых скриншотов резко сокращается — как мы уже знаем, требуется показать только самые «навороченные» настройки и сложные моменты. В сложных системах можно добавить схемы, показывающие взаимодействия между компонентами, направление потоков данных и т. д.
