слышим деление документации на виды, например «бывает проектная документация, а бывает продуктовая, так вот нам нужна продуктовая».
Чаще всего нам озвучивают вот такие дихотомии:
- техническая vs. пользовательская документация;
- проектная vs. эксплуатационная документация;
- проектная vs. продуктовая документация.
Я не очень понимаю, как устроены эти разделения на виды (где заканчивается техническая и начинается пользовательская документация?), да и сама идея делить документацию на две каких-то изолированных группы кажется мне принципиально неправильной.
Есть ли какие-то стандарты или методологии (ГОСТ? ИСО/МЭК?), где определяются эти виды документации?
Думаю, речь про гост 34.201... Техническая, она же проектная, это когда системы ещё нет, что должно быть на систему до написания кода. Рабочая, она же пользовательская - после написания кода. Эксплуатационная это та, что нужна после ввода системы в эксплуатацию. Продуктовой нет, она в головах отдельных людей, пусть говорят, что имеют в виду
Я тоже опираюсь на ГОСТ 34. Продуктовой тоже не встречалось определение, понимание на кончиках пальцев.
Поясните, пожалуйста, различие между эксплуатационной и пользовательской документацией. Первая предназначена для технических специалистов, которые будут систему в дальнейшем обслуживать (системные администраторы, девопсы), вторая — только для пользователей (бухгалтеры, операторы и т. п.). Верно?
На экспертность в этом вопросе не претендую. Сама понимаю так: пользовательская для пользователей, а эксплуатационная включает в себя и пользовательскую и для технических специалистов, обслуживающих систему и пользователей.
В России есть система постановки продукции на производство, которая ещё с советских времён пошла. И поскольку госты обязательны не всем и не всегда, то такую систему просто не внедряют. Хотя в идеале алгоритм разработки продукта такой: 1) научно-исследовательская разработка. Где со всех сторон написано обо всём. От терминов до технико-экономических показателей необходимости разработки. Собственно разработка 2) эскизный проект - формулировка общих принципов: что за разработка будет, как будет реализовываться. На выходе эскизная документация 3) технический проект (чаще всего этап объединяют с эскизным) - разрабатывается много документов со статусом решений: основные системотехнические решения. Решения по аппаратному обеспечению, по эргономике, по надёжности, по математическому обеспечению, по программному, по СУБД и тд... На выходе - техническая документация. И документации присваивается литера Т. 3) Разработка РКД - рабочая документация, необходимая при изготовлении собственно продукта массово. То есть это разные сборочные чертежи, технические условия, методики различных типов испытаний.. И, собственно, программная документация на этой же стадии. То есть сам текст программы! Непосредственно разработка и происходит на этой стадии! В том числе изготавливается и эксплуатационная документация, и методики испытаний. 4) Изготовление опытного образца. Предположим, взяли всю рабочую документацию - и отдали заводу-изготовителю. И по нашим чертежам они изготовили комплект для поставки. Включая и изговление комплекта документации, и запись по на диски, и изготовление, например, клиент-серверных устройств. На диски в определённом порядке записали все, например. И после того, как изделие пройдёт заводские испытания, документацию поправят где надо - документации присваивают литеру О. 5) Далее продукт показывают заказчику, также он проходит все испытания и проверку на соответствие требованиям тз. В конце концов утверждённая заказчиком документация получает литеру О¹ (типа утверждённый опытный вариант). При внесении изменений в конструкции и новой итерации всего предыдущего будет О², О³ итд... Далее изделие отправляют в массовое производство, и на этом этап разработки (проектирования) заканчивается, как и заканчивается его проектный этап. Дальше этап производства. Но, как правило, параллельно ещё и этап модернизации происходит, что то же самое, что и разработка. И если что-то придётся поменять в конструкции - проводятся уже типовые испытания, для которых также разрабатывается методика. Есть даже целая система проведения государственных испытаний и ГОСТ по ней. Ясно, что для госов обязателен, для оборонки все ГОСТы сверхобязательны, и есть ещё и свои, оборонные, где ещё +100500 процедур.... Для инициативных разработок, в общем-то, это всё тоже обязательно, но можно упростить. В спорах по авторским правам пригодится сохранить подобную структуру разработки, например. Но это отдельная песня.
Про авторские права и структуру не понял, раскрой мысль плиз
спасибо за емкие разъяснения! ирония в том, что чаще всего такие разделения на виды используют заказчики, у которых ни процессы, ни итоговая документация вообще никак не связаны с ГОСТ 34
и, например, после некоторого количества расспросов выясняется, что в голове у заказчика разделение примерно такое: - техническая документация адресована техническим специалистам (и в нее войдут внешние справочники API, инструкции по развертыванию) - пользовательская документация адресована конечным пользователям, которые априори считаются технически неподкованными (и термин «техническая» для такой документации как бы и не применим)
Некоторые в принципе не понимают, что им нужно из доков и зачем. Словно погуглили какие виды бывают. В одной конторе ПМ у меня на полном серьёзе спрашивал виды доков для каждого продукта. Я пыталась объяснить, что разными они быть не могут, что это плюс-минус один и тот же комплект, по хорошему. А он всё переспрашивал, ну так а для агрегатора какие? Такие же, как и для биллинга, говорю, а он мне, мол, почему, это ж разные продукты? Тоже самое пытался объснить новый техпис, которого на моё место брали. Две недели она онбордилась и за день до моего увольнения сказала, мол, ну их нафиг, не буду с ними работать, и что мне тоже повезло, что меня ушли))
да-да, у нас ровно такое примерно с каждым вторым заказчиком
У нас каждые день были миты по два часа только по вопросам доков - как они должны выглядеть, храниться и тп. Я просто обтекала... Мы вдвоём с ней поясняли, что такое древовидная структура и почему она удобнее, чем один док ворда на 100500 страниц, но ПМ и БА не понимали, что такое дерево. В прямом смысле. С аналогиями не сросталось.
как два дуба не могут понимать, что такое дерево? они в зеркало вообще смотрели?
А что вместо этого предлагали?
Вы не поверите... Ничего! У вас же опыт, вы предлагайте, вы проф, мы вам доверяем!
Они по ходу и содержания то автоматического слева в ворд не видели 😂
Ну, объективно, БА там была до мозга костей технарь, профдеформация на максималках, очень умная и техничная девочка, к ней нужен был определённый подход. Но нафига он её потащил на эти миры, которые ей не облокотились, так как она делает свою часть доков, которые потом ТЕХПИС должен привести к нужному формату?
Ненене, новый техпис предлагала именно прогу для хранения документации, показывала на примере своей, шарила экран... Я пыталась вставить хоть слово, но увы. Меня ж уволили уже почти, так как я кхм ну вы поняли (объективно, у меня опыта был кот наплакал, но всё равно блин!!!). И зачем-то таскали на эти миты. Она отказалась потом, высказала им, что ей для работы нет времени, ежедневный мит ей не нужен, раз в неделю норм, и две недели онбординга по 5-6 часов миты - и она за это время не написала ни один док, представляете?! Умиление.
Потому что документация по гост и не по гост - одно документация, и стандарты применимы)
могу предложить в копилку ещё исполнительскую документацию)) заказчик пришёл с госконтрактом, где это перл прописан в ТЗ говорю, что знаю исполнительную документацию, из времён инженерно-сметной работы, а исполнительской таки не существует)) что делать, говорит заказчик, нас не спрашивают, надо вот это сделать по ТЗ, как написано ну сделали, куда же деваться-то
Не сделали, а изобрели!)
сами-то документы обычные, ПЗ, схема КТС, архитектура, ПМИ и ПИ, ведомость ТП, акт приема-передачи
Напомнило, здесь, в чатике, пару недель назад человек изобретал "подробное ТЗ" в дополнение к обычному. Из той же оперы, видимо.
Это основное заблуждение :-) На ТЗ есть вполне себе четкие ГОСТы, если им следовать, все получится...ну в основном, мозг тоже надо включать. А вот если структуру придумывать самому, то получится или что-то похожее или это будет не ТЗ, а "перечень пожеланий".
Я думаю подробное тз - это и есть эскизно-технический проект... Где всё это абстрактное нечто в тз приобретает конкретные очертания. И по каждой группе требований - написано конкретное решение
На сколько я понял из контекста того давнего случая, "подробное" означает "менее общее, чем в прошлый раз, с меньшим количеством общих фраз". А так, все зависит от контекста практически полностью.
Это нормальный термин по ГОСТ 21.
Обсуждают сегодня