3. Оценка времени, необходимого на разработку технического документа
Следующим важным этапом планирования работы над документом является оценка времени, которое вы затратите на его создание. Здесь нужно учитывать весь временной промежуток от старта работы до сдачи готового результата заказчику (именно готового, а не первой или последующей проверочных версий). Чтобы правильно оценить необходимые временные затраты, нужно принять во внимание и проанализировать основные факторы, влияющие на скорость разработки документа.
Виды технических текстов и уровень их базовой сложности
Как и в других элементах работы, в первую очередь нужно понять, документ для какой ЦА вы пишете. При этом речь идёт не о заказчике, а о конечном пользователе документации.
1. Если вы пишете руководство пользователя, то все элементы самой программы надо разжевать до предела, при этом вдаваться в технические нюансы её работы не нужно — достаточно показать как программа или устройство работают «снаружи», то есть с точки зрения самого пользователя. Иными словами, вы указываете, какие кнопки нажимать при необходимости совершить какое-либо действие в программе или за какой рычаг и зачем тянуть на установке.
Для написания этих текстов можно обойтись минимумом знаний — сведениями о самой программе — достаточно вникнуть в суть её работы и описать это простым языком. Если же вы хотите получить более качественный и удобный пользователю документ, полезно будет знать не только саму программу, но и азы той области, для которой эта программа создана. Например, если вы пишете инструкцию к бухгалтерской программе, знание основ бухгалтерского учёта поможет вам приводить в тексте полезные для работы примеры, которые хорошо отразят суть описываемых вами функций программы. Также считается хорошим тоном, если в документации уже даются готовые ответы, описывающие не саму программу, а поясняющие, как с её помощью выполнить конкретную рабочую задачу. Чтобы писать в подобном кейсоориентированном стиле, опять же, потребуется знать не только и не столько само ПО, сколько суть той задачи, которую с его помощью предполагается решать. В противном случае, можно описать только саму программу, без связи с конкретными задачами и примерами.
Во втором случае вам придётся написать простой текст, но получить новые знания в предметной области, если раньше у вас их не было, в первом — лишь описать программу на уровне пользователя, что само по себе является одной из самых простых задач в техническом документировании.
