Разработка технической документации и технические писатели Технические писатели и разработка технической документации технические писатели в Телеграм 

 obmen_soobsheniyami.png Чат для технических писателей 
 Зарегистрируйтесь
Страницы: 1
Ответить
RSS
Какие средние сроки создания пакета документов?
 
Какие сроки надо давать техпису на создание пакета документов, состоящего из:
- Пояснительная записка к техническому проекту
- Программа и методика предварительных испытаний
- Программа опытной эксплуатации
- Руководство пользователя
- Руководство администратора
- Описание программного обеспечения
- Акт сдачи-приемки выполненных работ
При условии, что есть руководства на предыдущую версию и их надо актуализировать, из дополнительной документации только ТЗ.
 
На практике может быть необходимо от недели до года и даже более.
Зависит от:
-- объема и сложности документов,
-- количества и сложности изменений продукта по сравнению с предыдущей версией.
-- полноты, актуальности и качества документации предыдущей версии.

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

К тому же, если документов "Программа и методика предварительных испытаний" и "Программа опытной эксплуатации" не существует, значит, ни предварительных испытаний, ни опытной эксплуатации фактически не было.

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

Также непонятно, почему в ваш комплект документов входит пояснительная записка к техническому проекту, но не входит сам технический проект.
Описание программного обеспечения это лишь небольшая часть технического проекта.
 
Я отвечу из своего опыта подготовки документов по 34 ГОСТу.
В среднем я на один документ закладываю пару дней плотной безотрывной работы  (это при условии наличия у меня ВСЕЙ необходимой информации по проекту). Это будет первая итерация документов, к которой заказчик может давать замечания в зависимости от своей фантазии. С учетом того, что замечаний по существу документа как правило нет, и они носят характер: "запятая не того цвета" -  длительность стадии "улучшений" предугадать не получится.

Вам совершенно правильно сказали, что срок написания документов напрямую зависит от сложности самой программы. Если у Вас простенькая программулина - то такого срока вполне достаточно. Если это сложная программа в которой 150 отчетов, которые  нужно описать как формировать - то конечно это мало.

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

+ в настройках файла поставьте автосохранение: у меня стоит 1 минута и я этого не замечаю. Если при каждом сохранении у вас все зависает минут на дцать... то... В общем: все должно летать :)).

Если тупо взять тз, поменять в нем слово "должно быть " на "сделано", "разработано" - то пояснительная записка будет готова за несколько часов. Не ведитесь на автозамену - может поменять там, где не ждете.
Лучше через F5: и по подсвеченным словам пройтись.

Но по поводу пояснительной записки: там внутри есть несколько крупных разделов, которые иногда выносят в отдельные документы: описание автоматизированных функций, описание информационного обеспечения и описание ктс. (Это как раз к вопросу о техпроекте:  у нас это записка, описание по, описание информ обеспечения и описание автоматизированных функций, описание комплекса технических средств. В ГОСт конечно документов больше - но заказчик хочет так).  

Описание автоматизированных функций: если вы будет писать в ключе, что пользователь нажал туда-то, программа сделала то-то - это одно.
Если от вас требуется писать в ключе, что пользователь нажал туда-то , сформировался запрос такой (пример строки запроса), в этом запросе содержатся такие-то параметры (перечень параметров и какой для чего нужен), запрос передается  в базу данных, в результате возвращается ответ вида (пример строки ответа)  - то лучше обратиться к программисту. Сделайте ему пример описания функции - и потом получившийся результат вставите в документ.Как правило - они работают в каком-нибудь опенофисе или либерофисе. Заложите время на перенос текста из документа в документ. Можно сделать копию с Word документа и отдать, но у моих коллег эти опенофисы, так портят вордовский документ, что на форматирование уходит дикое кол-во времени. Проще перенести.

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

Описание КТС: если нужно быстро, то  тоже можно формально заменить какой-то схемой, перечнем серверов и т.п. - если есть архитектор (в худшем варианте сисадмин) - можно попросить у него. Наверняка такая информация есть, в каком виде- это уже другой вопрос.

Описание ПО: ну тут тоже если это формальный подход, то заполняете гостовый документ: из тз, переносите все, что можете заполнить, смотрите- какую информацию вам могут выдать программисты, в конце концов некоторые туда листинг вставляют.


Время написания  хорошего руководства пользователя с картинками и подписями к ним - зависит в том числе и от количества картинок в нем. В среднем на то, чтоб вставить одну картинку ( сделать скриншот, вставить в руководство, подписать её и сделать на неё ссылку в тексте через перекрестную ссылку) - у меня уходит от 30 секунд до минуты. Опять же в зависимости от того каким инструментом для снятия скриншота Вы пользуетесь и сколько картинок вы хотите вставить (потому что тогда список  картинок в перекрестной ссылке увеличивается и на выбор нужной ссылки тоже тратятся секунды) + быстродействие вашего компьютера.
Если Вы нажимаете PrintScreen и потом картинку обрезаете в Word - значит еще больше времени.Если сразу обрезаете нужную область (например,я пользуюсь Greenshot или ABBYY Screenshot Reader) - то быстрее.

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

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

Программа и методика: ну полдня - день. Опять же от подробности документа зависит. От самого ТЗ конечно тоже: 3 функции там, или 133.
Частично программу и методику можно передрать из руководства пользователя, если проверяются какие-то пользовательские функции.
Объем Вы сами регулируете. Например в ТЗ у вас есть требование: "пользователь должен иметь возможность отправить письмо с несколькими вложенными файлами".

Вы можете написать:
Шаг 1:пользователь нажимает туда-то - открывается окно почты + картинка
Шаг 2:Пользователь нажимает туда-то, открывается окно для выбора файлов+картинка
Шаг 3:Пользователь нажимает туда-то, активируется инструмент прикрепления файлов+картинка
Шаг 4:Пользователь удерживает Shift и выбирает несколько файлов и т.д. и т.п.

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

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

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

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

Акт сдачи-приемки выполненных работ готовит как правило бухгалтерия. Иногда: неправильно.Иногда проще самим подготовить, так как в акт надо  перенести РЕЗУЛЬТАТЫ работ из ТЗ.  Но не  у всех получается правильно перенести текст из одного документа в другой с первого  раза.
И не забыть еще напомнить секретарю  - чтоб сделали сопроводительное письмо, на то,что вы передаете заказчику. Тоже лучше список выдать, что будете передавать.А то всякое бывает....

ну вот как-то много у меня получилось текста... может быть что-то полезное всё-таки в нем есть :)))
 
Цитата
''Sher the Cat'' написал:
На предыдущую версию никаких документов, кроме руководств, не было. Меня просто крайне напрягает следующая, повторяющаяся ситуация: в понедельник вечером поставить задачу, в четверг уже сдавать документацию заказчику. Или это нормально и я просто медленно работаю?
Если вы спрашиваете, чтобы попытаться защитить себя от начальства, можете найти типовые нормы работы редактора/писателя (офиц. нормы). Там порядка нескольких страниц в день (!). Точные выходные данные нормативов я сейчас не скажу - могу посмотреть.
 
Цитата
Текрайтер из Питера написал: Там порядка нескольких страниц в день (!). Точные выходные данные нормативов я сейчас не скажу - могу посмотреть.
Интересно посмотреть, если не трудно опубликуйте
 
ГОСТ Р ИСО/МЭК 15910-2002

ПРОЦЕСС СОЗДАНИЯ ДОКУМЕНТАЦИИ ПОЛЬЗОВАТЕЛЯ ПРОГРАММНОГО СРЕДСТВА

ПРИЛОЖЕНИЕ F (справочное)

F.2 ПОМИНУТНЫЙ И ПОЧАСОВОЙ МЕТОДЫ

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

В начале проекта трудно оценить общий постраничный объем создаваемой документации. Если для завершения проекта требуется более 2 мес, подсчет страниц должен быть проведен по истечении первого месяца.

Для очень больших проектов номенклатура поставки должна быть разделена на части, поддающиеся управлению. При этом оценка сроков завершения проекта в целом может быть дана только в количестве месяцев, а детально может быть оценена лишь первая часть работы. При использовании данного метода документатор и заказчик должны сверить свои оценки сроков завершения проекта.

В таблице F.1 приведены сроки реализации «типового» (гипотетического) проекта. При этом предполагается, что автор готовит материалы непосредственно на персональном компьютере, и для их выпуска используют портативные издательские системы.

Таблица F.1 - Ориентировочные сроки
   
Этап
   
Срок
  Определение   номенклатуры поставки     16 ч   на проект  
  Исследование   содержания документации     24 ч   на проект  
  Написание   плана документирования     48 ч   на проект  
  Проектирование   структуры документа и правил оформления его страниц     8 ч   на том  
  Написание   первой редакции (документации)     1 ч   на страницу  
  Разработка   графических материалов     5 ч   на материал  
  Объединение   текстовых и графических материалов     30   мин на страницу  
  Проверка   первой редакции (эксперт)     30   мин на страницу  
  Корректировка   первой редакции и графики     30   мин на страницу  
  Внесение   замечаний пользователя     30   мин на страницу  
  Грамматическое   редактирование     15   мин на страницу  
  Подготовка   второй редакции (документации)     15   мин на страницу  
  Проверка   второй редакции (эксперт)     15   мин на страницу  
  Окончательная   корректировка документации     10   мин на страницу  
  Нормоконтроль   документации     15   мин на страницу  
  Изготовление   фотошаблонов     3 сут  
  Печать   и переплетение оригиналов     5 сут  
  Печать   и брошюровка копий     10   сут  
  Рассылка     1 сут  

F.3 МЕТОД НИСХОДЯЩЕГО ПРОЕКТИРОВАНИЯ

F.3.1 Общие положения

Данный метод основан на предположении, что число страниц в публикации(ях) может быть оценено достаточно просто с использованием следующих допущений:
a) автор может за месяц подготовить 22 страницы нового текста;
b) автор может за месяц подготовить 44 страницы текста с изменениями.
Например, объем публикации оценен в 150 страниц. Поскольку это новая публикация, получаем: 150/22 = 7чел./мес. В эти 7 мес. входят: планирование публикации, ее написание, редактирование и проверка двух редакций, а также подготовка фотошаблонов.

F.3.2 Пропорции
Продолжительность 7 чел./мес распределена в следующих пропорциональных отношениях:
a) 15 % - планирование (в данном примере - четыре недели);
b) 50 % - написание первой редакции (14 недель);
c) 25 % - написание второй редакции (семь недель);
d) 10 %- подготовка фотошаблонов (три недели).

F.3.3 Планирование
Период планирования охватывает:
a) исследования и подготовку плана;
b) изучение и проверку плана;
c) корректировку плана по результатам проверки.

F.3.4 Первая редакция
Период первой редакции охватывает:
a) подготовку содержания (плана-проспекта) документации;
b) изучение и проверку содержания (плана-проспекта);
c) подготовку пробного куска текста для редактора;
d) редактирование пробного куска текста и его переписывание по замечаниям редактора;
e) написание всей первой редакции документации;
f) редактирование всей первой редакции документации;
g) переработку отредактированной документации;
h) изучение и проверку переработанной документации.
Иллюстративные материалы готовят одновременно с текстом первой редакции.

F.3.5 Вторая редакция
Период второй редакции охватывает:
a) внесение в документацию всех изменений, предложенных по результатам проверки первой редакции;
b) повторное (второе)редактирование второй редакции документации;
c) переработку отредактированной документации;
d) изучение и проверку переработанной документации.

F.3.6 Принятая редакция
Редакцией для фотонабора является принятая редакция документирования. Ее подготовка охватывает:
a)     внесение в документацию всех изменений, предложенных по результатам проверки второй редакции;
b)     проверку правильности внесения данных изменений;
c)     удаление всех редакционных разметок;
d)     изготовление фотошаблонов;
e)     отправку фотошаблонов в печать (в типографию)
.
Обычно экспертам (нормоконтролерам) требуется от одной до двух недель для изучения и подготовки замечаний, а сама проверка занимает от одного до нескольких дней.

Метод нисходящего проектирования может быть использован для существующих публикаций. Например, книга объемом 100 страниц может быть переработана так, что половина ее изменяется и добавляется 10 % новых материалов. Используя вышепринятые допущения, получаем: 50/44 = 1,13 чел./мес для существующего материала плюс 10/22 = 0,45 чел./мес для внесения нового материала.

Когда сроки, необходимые для создания документации, превышают допустимые, для выполнения задания следует привлекать несколько авторов. Так же следует поступать при подготовке нескольких документов для одного программного средства.
Изменено: Виктор Фигурнов - 15.10.2015 10:13:08
 
writer написал:
Цитата
Цитата
Текрайтер из Питера   написал: Там порядка нескольких страниц в день (!). Точные выходные данные нормативов я сейчас не скажу - могу посмотреть.
Интересно посмотреть, если не трудно опубликуйте
Самих источников сейчас нет.

Посмотрите вот это:
1. Справочник базовых цен на разработку  ТД на автоматизированные системы утвержденный Минпромторгом 14 марта 1997 г.
2. Постановление Минтруда РФ от 25 ноября 1994 г. №72 Межотраслевые укрупненные нормативы времени на работы по документационному обеспечению управления.

Обычно после этих документов приводится 0.5-4 часа на 1 страницу A4 (но это среднее значение, как вы понимаете). Шрифт тоже может быть разным :)
 
2-5 страниц в день, в основном зависит от сложности функционала, логично что руководство пользователя написать можно быстрее, чем, например, описать архитектуру ПАК со всеми связями,  БД и т.д и т.п
 
Как по мне, следует обратится бы лучше к ним http://www.reglet.ru/ для переплета документов. Могла не по 2-5 странциц в день, в сразу бы всё  :)
Страницы: 1
Ответить
Читают тему
Форма ответов
 
Текст сообщения*
Загрузить файл или картинкуПеретащить с помощью Drag'n'drop
Перетащите файлы
Ничего не найдено
Загрузить файлы
Отправить Отменить