Здравствуй!
Сегодня расскажем про необходимый документоборот при создании своего инженерного проекта и нашем опыте при разработке ракеты с ЖРД. Продолжаем цикл статей о нашем пути в создании такого сложного изделия. Кране рекомендуется ознакомиться с предыдущими частями для понимания полноты картины.
1 часть – Как не надо начинать
Поговорим о документации. Тема самая противоречивая, ибо каждый второй говорит, что он знает как правильно, ведь на его заводе делали именно так и никак по-другому. Автор просто расскажет о своем опыте и к чему по итогу пришел коллектив, достаточно отработав данную тему с документооборотом. Так что читатель сделает свои выводы самостоятельно.
Думаю, можно сказать, что наш опыт – опыт технического проекта, рассчитанный на коллектив от 5 до 25 человек (примерно). Проект не занимается перепиской с государственными предприятиями и не сдает отчеты о проделанной работе. То есть - у коллектива есть возможность не делать вообще никакую документацию, но, как показала практика, это тоже не есть правильно.
Начну с того, как мы начали. Коллектив стартанул с людьми, которые в свое время немного поработали в отрасли (ракетно-космической) и в некоторых частных (да, космических) компаниях. Данный «опыт» продиктовал нам, что надо делать все по требованиям ГОСТов и ОСТов. Думаю необходимо немного пояснить.
Автор очень сильно попытается относительно кратко и доступно описать каким образом в больших предприятиях происходит «создание» чего-либо. Да, в описанном могут быть неточности и, скорее всего, автор не в полной суперглубокой мере знает все, но идет описание крупными мазками. Плюсом возможно отличие многих этапов и их исполнения.
Предположим, вы хотите сделать крутую суперкрутую лампочку (автор сидит в кафе и это первое что попало на глаза). За «Лампочку» взято что-то большое, например ракетный комплекс или, например, новый самолет.
Итак, идея пришла, для начала ее надо проверить с точки зрения «теории». Для этого в отрасли имеются научно-исследовательские институты, которые как раз этим и занимаются. Производится научно-исследовательская работа (НИР). По результатам данной работы вы уже можете понять, стоит вам делать эту лампочку. То есть, производится оценка, расчеты, предположения, изучения с научной точки зрения надо ли оно вообще кому-то.
Далее, помимо договоров, что за предприятие будет разрабатывать ту или иную тему производится написание «Аванпроекта». А точнее технического задания на него. Вообще каждый фундаментальный этап сопровождается техническим заданием, планом-графиком работ и прочими сопроводительными документами. Аванпроект — это этап, по которому производится предварительная проработка (довольно крупная, то есть по узлам и системам) изделия. По ее результатам предлагается несколько вариаций реализации лампочки. Мол, есть вот такая круглая с вольфрамовой нитью, есть вот такая овальная с графитовой вставкой и прочее. Рассматриваются их плюсы и минусы.
После того как определились с вариантом лампочки (какой больше нравится заказчику под его требования). Начинается фундаментальный этап «Эскизного проекта». Многие считают, что слово «эскиз» означает, что его нарисуют на бумажке и этим все завершится. К сожалению или, к счастью, это не так. Данный этап совершает выпуск всей конструкторской документации (КД) по данному изделию. То есть производится проектирование, расчет каждого узла, оформление, согласование и выпуск всего комплекта чертежей. В дальнейшем изготавливаются детали, узлы, проводятся испытания по написанным методикам, производятся правки изделия и ввод его в эксплуатацию.
Я так пишу все это легко. Удивляет то, что за этими «этапами», сроками проходят года, порой даже десятилетия упорной работы сотней и тысяч людей. Надеюсь, я довел до читателя, что все это не есть просто и, в отличие от распространенного мнения «что это все не нужно, бюрократию развели и ничего не делают» без всего этого по-настоящему крупные изделия работать не будут, ибо все сделано будет абы как.
Вернусь к нам, начали мы с написания документа-обоснования, зачем мы вообще хотим все это делать. Наша идея была проста и лаконична. Ракеты сверхлегкого класса делают во всем мире, а у нас не делают. Надо сделать в нашей стране и вообще показать всем. «Да в отрасли одни деды работают, вот мы им покажем, как надо». Господи, как мы были глупы)
Ну да ладно, наша идея была в том, чтобы «постепенно» создавать ракеты, которые будут взлетать все выше и выше. Тестировать технологии и по итогу создать ракету, способную доставить на орбиту спутник.
Вообще, смотря назад, идея была логичной и даже немного прорывной для своего времени, ибо наши коллеги (студенты и другие «новые частные компании») говорили, что сделают космическую ракету сразу, без всяких демонстраторов. Так что наш «ступенчатый» путь был нашей фишкой, благодаря которой мы считали себя реалистами.
Дополнительной идеей, которая впоследствии стала основной и ключевой – это обучение студентов на практике созданию настоящей ракеты. То есть, не по книжкам, а прям руками, все посчитать и сделать с самого нуля невероятно круто звучит даже сейчас. «Новый ГИРД». Идея была крутая и я думаю это единственная цель, которую мы, по правде, достигли.
После написания обоснования и набора команды мы преступили к написанию «Технического задания на аванпроект ракетного комплекса «Мечта-1». И да, название ракеты - «Мечта», красиво, не правда ли?)
По итогу работ мы много раз пытались пересмотреть вариации ведения документации. Нас бросало из крайности в крайность. По итогу можем подвести небольшой итог той документации, которая действительно необходима и не будет вас сильно утомлять:
Обоснование проекта. Документ, аналогичный НИРу. В нем вам надо хотя бы для себя понять, зачем вы вообще хотите сделать ту или иную вещь. Пропишите конкурентов, аналоги, их плюсы и минусы, параметры их изделий. Если какой-то из проектов умер, найдите причину данному событию, его причины. Обязательно надо прописать «Миссию» проекта. Про это много статей и практик, важно – чтобы вы верили в то, что напишите. По итогу должен быть документ, в котором описано вышеперечисленное. Дополнительно необходимо отработать так называемый Elevator-speech. Это ситуация, в которой вам необходимо максимально кратко (за минуту) рассказать, чем вы занимаетесь и почему некому инвестору надо вас вложиться, про это вагон статей на нашем любимом Хабре.
Техническое задание. По нашей практике, этап аванпроекта не так необходим, ибо рассмотрение различных вариаций изделия происходит на этапе предварительного расчета. Но, как и отмечалось раньше, это опционально. Условно можно сказать, что при после написания обоснования проекта вы входите в этап «Эскизника», но тут уже как вам больше нравится. Итак, техническое задание - документ, который является главным для вас и вашего проекта. Как показала практика, это невероятно полезно как минимум – это навык составления документов подобного рода, как максимум – данный документ можно и нужно показать кому-то, если спросят важные ребята. Данный документ описывает итог, к которому вы должны прийти. Что за изделие вы изготавливаете, какими требования оно должно удовлетворять, какие параметры должно достичь изделие. Чем лучше вы его пропишите – тем лучше. Не обязательно уходить в оформительский угар. В общей практике данный документ нужен для того, чтобы исполнители сделали в точности то, чего хочет заказчик, ведь исполнитель хочет достичь данную цель с минимальными силами) Именно поэтому ТЗ прописывается так подробно. Если вы и заказчики и исполнители работы – данный файл нужен ВАМ и никому другому. Про содержание ТЗ немного описано в 1 части данного повествования. Если необходимо рассмотреть эту тему подробнее – дайте знать.
Схема деления. Документ, который в начале нам, как маслятам, показался ненужным, оказывается очень-очень полезным. Надеюсь, что читатель хоть немного знаком с такой вещью как «спецификация». Представьте себе генеалогическое древо. Имеется отец, у которого был сын, у него другой сын и так далее. Это примерно тоже самое. Рассмотрим на примере (вариант самый первый и впоследствии был конечно же доработан).
Ключевой продукт – это «Ракетный комплекс», то есть совокупность наземного стартового комплекса и ракеты (не ракеты-носителя). Сама ракета состоит уже из головной части с полезной нагрузкой и ракеты-носителя, которая в свое время состоит из конструктивных элементов и прочее. Думаю, мысль ясна, схема деления – документ, который помогает вам, как разработчикам, разбивать работу, зоны ответственности, даже построения отделов (какой чем занимается). Дополнительно именно по данному документу строится общая спецификация на «ракетный комплекс», но про это отдельно.
План-график. Документ распространенный, представляет собой «Диаграмму Ганта» со сроками, которые вы ставите себе.
С вероятностью 99 процентов, если вы не работали минимум лет 5 в данной сфере (условно), то сроки у вас уедут «вправо». В нашей практике документ показал себя как полностью бесполезный, ибо сроки улетали всегда и очень-очень на много, ибо мы были совсем маслятами и думали, что все можно сделать за год аахахахах)
НО
Это не значит, что сроки себе ставить не надо. Попробуйте расписать, из каких этапов будет состоять ваш проект, проставьте сроки, которые оптимальны по вашему мнению и наблюдайте, за собой – это полезно)
Спецификации и сборочные чертежи. Как показала практика, в качестве МИНИМАЛЬНОГО документооборота для проекта подобного рода крайне необходимы спецификации и сборочные чертежи на все изделия, которые вы делаете. Это необходимо по нескольким причинам:
-
Внутренний порядок – вы понимаете, что за чем идет, какие части чему принадлежат - то есть это убирает бардак в голове как новопришедшего человека, который видит ваш пепелац в первый раз, так и вас, как разработчика, который мог что-то забыть)
-
Общая сборка изделия. Очень часто складывается ситуация, при которой вам необходимо собрать всю ракету или двигатель воедино. При наличии документа вы можете это сделать без вопросов «а точно тут так?».
-
Простое обсуждение. «А какие болты крепят фланец в двигателя?», «а какой размер отсека системы спасения?» - чтобы не рыться непойми где необходимо хоть в общем виде делать сборочные чертежи ваших изделий. Не так обязательно их жестко оформлять – накиньте модель и проставьте общую информацию. Это очень сильно упростит вам жизнь.
-
Упрощенный состав запасных инструментов и приспособлений (ЗИП). Ситуация – вы выезжаете на запуск и необходимо взять запасные детали, отвертки, изоленту и т.п. Для этого необходимо снова думать, а что там за болт, какие детали нужны и прочее. А так взяли – посмотрели и составили ЗИП гораздо быстрее (так как всем до него нет дела, и он окладывается в последний момент, время — это решающий фактор вашего успеха)
-
Да это просто полезно, ибо на любой инженерной работе вам придется иметь с этим дело)
Хочется отметить, что в спецификации необходимо заранее, в начале проекта, при составлении схемы деления, заложить кодификатор ваших изделий. Это можно сделать по ГОСТ 2.201-80. Очень важная штука.
Предвосхищаю вопрос об обычных чертежах. В идеале – это вещь крайне важная, но если вы оперируете только с 3D-моделями, то это для вас может занять много времени практически без выхлопа (ой и закидают меня за это). Если же вы хотите отдать какую-то деталь на производство в аутсорс, то да, конструкторская документация должна быть. Никакой токарь (если он не работает с ЧПУ) не будет брать вашу модель. Точить надо по бумажной КД.
Дополнительно добавлю - автор не говорит, что не надо делать чертежи. Автор пытается донести, что данная необходимость зависит от типа проекта и организации, на базе которой производятся работы.
По итогу работ, мы вывели для себя именно такую формулу. Как уже было сказано ранее – это все опционально. Так что надеюсь масленок, прочитавший эту статью, возьмется за изучение ЕСКД, но и ракеты не забудет)
Надеюсь было хоть чуточку понятно и полезно, спасибо за прочтение, следующая статья наконец о нашем первом практическом фиаско - уже совсем скоро)
Автор: spacesteel
