Номенклатура техдокументации

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

Ответственным за работу ресурса назначаю Незнакомку.

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

2. Рассылку писем дружественным ресурсам считаю преждевременной - не готова платформа. В конце концов, нет Устава Ассоциации.

3. Портал готовится локально, посему выложенный в сети "пробник" повис в первозданном виде.

Сначала зарегистрироваться на сайте, потом запущу в админку.

А как туда войтить, собсно?

Админка - http://author-it.ru/administrator/

Ну вот... На ресурсе http://author-it.ru запущена CMS Joomla, позволяющая интегрировать множество разрозненных писательских ресурсов. Причем неважно, хотят они этого или не хотят. Проинтегрировал - и нии....

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

Ответственным за работу ресурса назначаю Незнакомку.

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

Здравствуйте, коллеги,

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

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

У меня предложение было примерно следующее.

Виды работ:

a) Документирование продуктов.

b) Документирование эксплуатируемых систем.

c) Документационное сопровождение проектов.

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

Формы работы:

I) Разработка комплекта технической документации (аккордная оплата, стоимость и сроки оценивает исполнитель до заключения договора, приложением к договору идет ТЗ на комплект).

II) Абонентское обслуживание (сдельная оплата, в договоре указан повременный или постраничный тариф или несколько тарифов).

III) Организация документирования в компании (фактически, консалтинговая услуга).

Такое деление хорошо тем, что позволяет найти подход к заказчикам с разными установками. Например, заказчику, у которого семь пятниц на неделе, подойдет форма работы II. Он то откапывает яму, то опять закапывает, а у нас время идет, и оплата идет. Заказчику, который говорит: "Я хочу четко знать, что я получу в конце за свои деньги", подойдет форма I (а для исполнителя эта форма хороша тем, что стимулирует его сосредоточиться на сути задачи и побыстрее ее решить, а не гнать объем и тянуть время, чтобы побольше заработать).

На "пересечении" вида и формы находится услуга, т.е. нечто что можно измерить и продать.

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

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

Ну это я предлагаю пока отложить... тут бы намеченное реализовать:)

В техпроекте разрабатывается проект ТУ, который становится ТУ после межведомственных испытаний изделия.

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

Еще что забыли — метрологию и сертификацию. Первая очень нужна при разработке ПМ, вторую тоже часто требуют военные. Кадры можно найти в Питере, все же ВНИИ метрологии у нас.

Это только в том случае, когда нет ТЗ.
Недавно тех.проект (по ТЗ) сдавали - даже речи об этом не было.

Да, этим (хотя и не только этим конечно) он и отличается от эскизного:)

А разве в техпроекте разрабатывается ТУ?

Я считаю, что номенклатура, обозначенная Алексеем, полна и достаточна. Не вызывает вопросов и номенклатура, приведенная Сергеем. Осталась расшифровка ТД на АС (ес-но, за Алексеем). Все это бы свести в таблицу, куда каждый из нас мог вписать свое ФИО о том, что он способен и берется за такой вид работ, чтобы оценить наши возможности, ресурсы и возможные дыры. Пара конструкторов на чертежи у меня есть. Раз Алексей начал, ему и заканчивать эту работу.

По п. а)
В этапы разработки ПО лезть особо на мой взгляд не стоит - у программеров свои технологии. А поэтому номенклатура документации на ПО будет будет состоять как из гостированных:

Техническое задание
Спецификация
Программа и методика испытаний
Описание программы
Ведомость ЭД
Формуляр
Описание применения (по большому счету нафик не нужно, т.к. все эти сведения спокойно можно изложить в руководствах, но тем не менее)
Руководство системного программиста
Руководство оператора
Руководство по техническому обслуживанию

...так и обойденные вниманием гостов:

Руководство пользователя
Руководство администратора
и т.д. - Михаил может дополнить, основываясь на своем опыте

[/]

[/]

Начну с п. б) как наиболее близкого мне:)

1. Техническое предложение
Данный этап является экзотикой (лично для меня) поэтому здесь приведу только основные документы. Может кто-нибудь сможет дополнить перечень, исходя из личного опыта.

Ведомость технического предложения
Пояснительная записка к техническому предложению

2. Эскизный проект
Здесь как и в техническом проекте, и в рабочей документации я не учитываю чертежи и схемы, как я уже говорил - это отдельная песня. К тому же мы не конструктора:( Вот разработка 3Dмоделей деталей и сборочных единиц на основе чертежей - это запросто:)

Ведомость эскизного проекта
Пояснительная записка к эскизному проекту
Ведомость покупных изделий
Программа и методика испытаний (макетов)

3. Технический проект

Ведомость технического проекта
Пояснительная записка к технического проекту
Ведомость покупных изделий
Технические условия
Программа и методика испытаний (макетов)

4. Рабочая документация

Ведомость спецификаций
Спецификация
Ведомость покупных изделий
Технические условия
Программы и методики испытаний (опытного образца, приемосдаточные, квалификационные и т.д. и т.п.)
Инструкция по настройке (по ОСТ 4Г 0.000.040)
Инструкция по упаковыванию (по ГОСТ 2.418-77)
Ведомость ЭД
Руководство по эксплуатации
Инструкция по монтажу, пуску, регулированию и обкатке изделия
Формуляр
Паспорт
Этикетка
Ведомость ЗИП
Каталог сборочных деталей и единиц
Ведомости расхода

Далее сюда же можно добавить оформление документации при проведении ОКР. В этом случае вместо этапа Тех. предложение будет стоять этап Разработка ТЗ на ОКР. Плюс к этому можно будет приложить сопровождение в виде многочисленных актов, протоколов и решений, которые требуются на различных этапах ОКР и как показывает практика вызывают некоторый ступор у исполнителей.

[/]

[/]

[/]

[/]

Не сочтите за буквоеда, но пункты б) и в) уже предполагают разработку КД - пункт л) явно лишний:)