Ведомость технического проекта
ГОСТ 2.102-68. ЕСКД. Виды и комплектность конструкторских документов
ГОСТ 2.102-68. ЕСКД. Виды и комплектность конструкторских документов|
УДК 62(084.11):006.354 |
Группа Т52 |
Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р
|
Единая система конструкторской документации |
(СТ СЭВ 4768-84) |
|
Unified system for design documentation. |
Дата введения 1971-01-01
Настоящий стандарт устанавливает виды и комплектность конструкторских
документов на изделия всех отраслей промышленности.
Стандарт полностью соответствует СТ СЭВ 4768-84.
(Измененная редакция, Изм. № 3).
1. ВИДЫ КОНСТРУКТОРСКИХ ДОКУМЕНТОВ
1.1. К конструкторским документам (именуемым в дальнейшем словом "документы") относят графические и текстовые документы, которые в отдельности или в совокупности определяют состав и устройство изделия и содержат необходимые данные для его разработки или изготовления, контроля, приемки, эксплуатации и ремонта.
1.2. Документы подразделяют на виды, указанные в табл. 1.
Таблица 1
| Вид документа | Определение |
|---|---|
| Чертеж детали | Документ, содержащий изображение детали и другие данные, необходимые для ее изготовления и контроля |
| Сборочный чертеж | Документ, содержащий изображение сборочной единицы и другие данные,
необходимые для ее сборки (изготовления) и контроля. |
| Чертеж общего вида | Документ, определяющий конструкцию изделия, взаимодействие его составных частей и поясняющий принцип работы изделия |
| Теоретический чертеж | Документ, определяющий геометрическую форму (обводы) изделия и координаты расположения составных частей |
| Габаритный чертеж | Документ, содержащий контурное (упрощенное) изображение изделия с габаритными, установочными и присоединительными размерами |
| Электромонтажный чертеж | Документ, содержащий данные, необходимые для выполнения электрического монтажа изделия |
| Монтажный чертеж | Документ, содержащий контурное (упрощенное) изображение изделия, а
также данные, необходимые для его установки (монтажа) на месте применения. |
| Упаковочный чертеж | Документ, содержащий данные, необходимые для выполнения упаковывания изделия |
| Схема | Документ, на котором показаны в виде условных изображений или обозначений составные части изделия и связи между ними |
| Спецификация | Документ, определяющий состав сборочной единицы, комплекса или комплекта |
| Ведомость спецификаций | Документ, содержащий перечень всех спецификаций составных частей изделия с указанием их количества и входимости |
| Ведомость ссылочных документов | Документ, содержащий перечень документов, на которые имеются ссылки в конструкторских документах изделия |
| Ведомость покупных изделий | Документ, содержащий перечень покупных изделий, примененных в разрабатываемом изделии |
| Ведомость разрешения применения покупных изделий | Документ, содержащий перечень покупных изделий, разрешенных к
применению в соответствии с ГОСТ 2. |
| Ведомость держателей подлинников | Документ, содержащий перечень предприятий (организаций), на которых хранят подлинники документов, разработанных и (или) примененных для данного изделия |
| Ведомость технического предложения | Документ, содержащий перечень документов, вошедших в техническое предложение |
| Ведомость эскизного проекта | Документ, содержащий перечень документов, вошедших в эскизный проект |
| Ведомость технического проекта | Документ, содержащий перечень документов, вошедших в технический проект |
| Пояснительная записка | Документ, содержащий описание устройства и принципа действия разрабатываемого изделия, а также обоснование принятых при его разработке технических и технико-экономических решений |
| Технические условия | Документ, содержащий требования (совокупность всех показателей, норм, правил и положений) к изделию, его изготовлению, контролю, приемке и поставке, которые нецелесообразно указывать в других конструкторских документах |
| Программа и методика испытаний | Документ, содержащий технические данные, подлежащие проверке при испытании изделий, а также порядок и методы их контроля |
| Таблица | Документ, содержащий в зависимости от его назначения соответствующие данные, сведенные в таблицу |
| Расчет | Документ, содержащий расчеты параметров и величин, например, расчет
размерных цепей, расчет на прочность и др. |
| Эксплуатационные документы | Документы, предназначенные для использования при эксплуатации, обслуживании и ремонте изделия в процессе эксплуатации |
| Ремонтные документы | Документы, содержащие данные для проведения ремонтных работ на специализированных предприятиях |
| Инструкция | Документ, содержащий указания и правила, используемые при изготовлении изделия (сборке, регулировке, контроле, приемке и т. п.) |
(Измененная редакция, Изм. № 1, 4, 7).
1.3. Документы в зависимости от стадии разработки подразделяются на проектные (техническое предложение, эскизный проект и технический проект) и рабочие (рабочая документация).
1.4. Наименования конструкторских документов в зависимости от способа их выполнения и характера использования приведены в табл. 2.
Таблица 2
| Наименование документа | Определение |
|---|---|
| Оригиналы | Документы, выполненные на любом материале и предназначенные для изготовления по ним подлинников |
| Подлинники | Документы, оформленные подлинными установленными подписями и
выполненные на любом материале, позволяющем многократное воспроизведение с
них копий. |
| Дубликаты | Копии подлинников, обеспечивающие идентичность воспроизведения подлинника, выполненные на любом материале, позволяющем снятие с них копий |
| Копии | Документы, выполненные способом, обеспечивающим их идентичность с
подлинником (дубликатом) и предназначенные для непосредственного
использования при разработке, в производстве, эксплуатации и ремонте
изделий
Копиями являются также микрофильмы-копии, полученные с микрофильма-дубликата. |
(Измененная редакция, Изм. № 4).
1.5. Документы, предназначенные для разового использования в производстве
(документы макета, стендов для лабораторных испытаний и др. ), допускается
выполнять в виде эскизных конструкторских документов. Наименования эскизных
документов в зависимости от способа выполнения и характера использования
аналогичны приведенным в табл. 2.
2. КОМПЛЕКТНОСТЬ КОНСТРУКТОРСКИХ ДОКУМЕНТОВ
2.1. При определении комплектности конструкторских документов на изделия следует различать:
- основной конструкторский документ;
- основной комплект конструкторских документов;
- полный комплект конструкторских документов.
2.2. Основной конструкторский документ изделия в отдельности или в совокупности с другими записанными в нем конструкторскими документами полностью и однозначно определяют данное изделие и его состав.
За основные конструкторские документы принимают:
- для деталей - чертеж детали;
- для сборочных единиц, комплексов и комплектов - спецификацию.
Изделие, примененное по конструкторским документам, выполненным в
соответствии со стандартом Единой системы конструкторской документации,
записывают в документы других изделий, в которых оно применено, за обозначением
своего основного конструкторского документа. Считается, что такое изделие
применено по своему основному конструкторскому документу.
2.3. Основной комплект конструкторских документов изделия объединяет конструкторские документы, относящиеся ко всему изделию (составленные на все данное изделие в целом), например, сборочный чертеж, принципиальная электрическая схема, технические условия, эксплуатационные документы.
Конструкторские документы составных частей в основной комплект документов изделия не входят.
2.4. Полный комплект конструкторских документов изделия составляют (в общем случае) из следующих документов:
- основного комплекта конструкторских документов на данное изделие;
- основных комплектов конструкторских документов на все составные части данного изделия, примененные по своим основным конструкторским документам.
Пример построения полного комплекта конструкторских документов комплекса
приведен в приложении.
2.5. В основной комплект конструкторских документов изделия могут входить также групповые конструкторские документы, если эти документы распространяются и на данное изделие, например, групповые технические условия.
2.6. Номенклатура конструкторских документов, разрабатываемых на изделия, в зависимости от стадий разработки приведена в табл. 3.
Таблица 3
| Код документа | Наименование документа | Техническое предложение | Эскизный проект | Технический проект | Рабочая документация на | Дополнительные указания | |||
|---|---|---|---|---|---|---|---|---|---|
| детали | сборочные единицы | комплексы | комплекты | ||||||
| - | 1. | - | - | О1 | 1 | - | - | - | Допускается не выпускать чертеж в случаях, оговоренных в ГОСТ 2.109-73 |
| СБ | 2. Сборочный чертеж | - | - | - | - | 2 | - | - | - |
| ВО | 3. Чертеж общего вида | О | О | - | - | - | - | - | |
| ТЧ | 4. Теоретический чертеж | - | О | О | О | О | О | - | - |
| ГЧ | 5. | О | О | О1 | О1 | О2 | О | - | - |
| МЭ | 5а. Электромонтажный чертеж | - | - | - | - | О | - | - | - |
| МЧ | 6. Монтажный чертеж | - | - | - | - | О2 | О | О | - |
| УЧ | 6а. Упаковочный чертеж | - | - | - | О | О | О | О | - |
| По ГОСТ 2.701-84 | 7. Схемы | О | О | О | - | О | О | О | Номенклатура различных видов схем установлена ГОСТ 2. |
| - | 8. Спецификация | - | - | - | - | Спецификацию комплектов монтажных, сменных и запасных частей, инструмента, принадлежностей и материалов, укладок, тары допускается не составлять, если изделия и материалы, входящие в комплект, целесообразно записывать непосредственно в спецификацию изделия, для которого они предназначаются | |||
| ВС | 9. Ведомость спецификаций | - | - | - | - | О | О | О | Ведомость спецификаций рекомендуется составлять на комплексы и сборочные единицы, имеющие две и более ступени входимости составных частей и предназначенные для самостоятельной поставки. При передаче конструкторской документации предприятию-изготовителю составление ведомости спецификаций на эти изделия обязательно |
| ВД | 10. | - | - | - | - | О | О | О | Ведомость ссылочных документов составляют при передаче конструкторской документации предприятию-изготовителю, ее допускается выпускать к моменту передачи документации. При передаче документации на комплекс допускается составлять только одну (общую) ведомость на всю передаваемую документацию комплекса |
| ВП | 11. Ведомость покупных изделий | - | О | О | - | О | О | О | Ведомость покупных изделий рекомендуется составлять на изделия, предназначенные для самостоятельной поставки |
| ВИ | 12. Ведомость разрешения применения покупных изделий | - | О | О | - | О | О | О | Ведомость разрешения применения покупных изделий рекомендуется составлять на изделия, предназначенные для самостоятельной поставки |
| ДП | 13. | - | - | - | - | О | О | О | Ведомость технического предложения, ведомость эскизного проекта, ведомость технического проекта и пояснительную записку для сборочных единиц и комплексов не составляют, если они входят в состав более сложного изделия (например, в комплекс), на которое составлены эти документы, содержащие все необходимые сведения по входящим в них сборочным единицам и комплектам |
| ПТ | 14. Ведомость технического предложения | - | - | - | - | - | - | ||
| ЭП | 15. Ведомость эскизного проекта | - | - | - | - | - | - | ||
| ТП | 16. | - | - | - | - | - | - | ||
| ПЗ | 17. Пояснительная записка | 3 | 3 | 3 | - | - | - | - | |
| ТУ | 18. Технические условия | - | - | О | О | О | О | О | Технические условия составляют на изделия, предназначенные для
самостоятельной поставки (реализации) потребителю. По согласованию
потребителя (заказчика) и поставщика (разработчика) конструкторской
документации технические условия могут быть составлены на отдельные
составные части изделия.
Технические условия на изделия народнохозяйственного назначения
единичного производства разового изготовления не составляются. |
| ПМ | 19. Программа и методика испытаний | - | О | О | О | О | О | - | - |
| ТБ | 20. Таблицы | О | О | О | О | О | О | О | Номенклатура необходимых таблиц, расчетов, инструкций и прочих документов устанавливается разработчиком в зависимости от характера и условий производства изделий |
| РР | 21. Расчеты | О3 | О3 | О3 | О | О | О | О | |
| И. | 21а. Инструкции | - | - | - | О | О | О | О | |
| Д... | 22. Документы прочие | О | О | О | О | О | О | О | |
| 23. (Исключен, Изм. № 4). | |||||||||
| По ГОСТ 2.601-68 | 24. Документы эксплуатационные | - | - | - | О | О | О | О | Номенклатура и обязательность выполнения эксплуатационных документов установлена ГОСТ 2.601-68 |
| По ГОСТ 2.602-68 | 25. Документы ремонтные | - | - | - | О | О | О | О | Номенклатура и обязательность выполнения ремонтных документов
установлена ГОСТ 2. |
Условные обозначения:
- документ обязательный;
О - документ составляют в зависимости от характера, назначения
или условий производства изделия с учетом требований, изложенных в графе
"Дополнительные указания ";
- - документ не составляют.
Примечания:
1. Документы, для которых над условными обозначениями проставлены одинаковые цифры, могут быть по усмотрению разработчика совмещены. При этом совмещенному документу присваивается код и наименование документа, имеющего наименьший порядковый номер по табл. 3.
2. Номенклатура конструкторских документов изделий, разрабатываемых по заказам Министерства обороны, должна быть с ним согласована.
3. Документы, предназначенные для изделий единичного и вспомогательного производств, допускается выполнять с упрощениями, указанными в ГОСТ 2.109-73 и ГОСТ 2.503-90.
(Измененная редакция, Изм. № 1, 2, 4, 5, 6, 7).
ПРИЛОЖЕНИЕ
ПРИМЕР ПОСТРОЕНИЯ ПОЛНОГО КОМПЛЕКТА КОНСТРУКТОРСКИХ ДОКУМЕНТОВ КОМПЛЕКСА
Примечания:
1. Основной конструкторский документ изделия показан в овале.
2. Документы основного комплекта показаны в прямоугольниках (в примере показана только часть документов основного комплекта, предусмотренных в табл. 3).
3. Документы, обведенные в двойные рамки, предусматриваются только для изделий, предназначенных для самостоятельной поставки.
4. Число ступеней входимости для комплексов, сборочных единиц и комплектов, а также число входящих комплектов сборочных единиц, комплектов и деталей не ограничиваются.
(Измененная редакция, Изм. № 4).
ИНФОРМАЦИОННЫЕ ДАННЫЕ
1. РАЗРАБОТАН И ВНЕСЕН Комитетом стандартов, мер и измерительных приборов при Совете Министров СССР
РАЗРАБОТЧИКИ:
В. Р. Верченко, Ю.И. Степанов, А.А. Ваксман, С.С. Борушек,
Б.Ш. Каплун, Л.К. Голубев
2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Комитета стандартов, мер и измерительных приборов при Совете Министров СССР 28.06.68 № 1029
3. Стандарт полностью соответствует СТ СЭВ 4768-84
4. ВЗАМЕН ГОСТ 5295-60 в части разд. I и II и ГОСТ 5291-60
5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
| Обозначение НТД, на который дана ссылка | Номер пункта |
|---|---|
| ГОСТ 2.109-73 | 2.6 |
| ГОСТ 2.124-85 | 1.2 |
| ГОСТ 2.503-90 | 2.6 |
| ГОСТ 2.601-68 | 2.6 |
| ГОСТ 2.602-68 | 2.6 |
| ГОСТ 2.701-84 | 2.6 |
6. ПЕРЕИЗДАНИЕ (март 1995 г.) с Изменениями № 1, 2, 3, 4, 5, 6, 7,
утвержденными в августе 1981 г., ноябре 1981 г., марте 1985 г., сентябре 1985
г., октябре 1986 г., сентябре 1987 г., июле 1988 г. ( № 10-81, 4-82, 5-85,
12-85, 1-87, 12-87, 11-88)
Используются технологии uCoz
Разработка конструкторской документации
Конструкторская документация – совокупность конструкторских документов, содержащих данные, необходимые для проектирования (разработки), изготовления, контроля, приемки, поставки, эксплуатации, ремонта, модернизации, утилизации изделия.
Основные этапы выполнения конструкторской документации (КД):
1. Разработка проектной КД
Стадия проектной КД включает в себя разработку технического предложения по результатам анализа ТЗ, эскизного и технического проекта.
2. Разработка рабочей КД
Стадия рабочей документации состоит из КД опытной партии, серийного производства или единичного производства.
После согласования проектной и рабочей конструкторской документации выполняются стадии изготовления, поставки и эксплуатации при участии проектной организации.
Конструкторские документы подразделяют на виды, представленные ниже.
Электронная модель детали
Документ, содержащий электронную геометрическую модель детали и требования к ее изготовлению и контролю. В зависимости от стадии разработки он включает в себя предельные отклонения размеров, шероховатости поверхностей и др.
Чертеж детали
Документ, содержащий изображение детали и другие данные, необходимые для ее изготовления и контроля.
Электронная модель сборочной единицы
Документ, содержащий электронную геометрическую модель сборочной единицы, соответствующие электронные геометрические модели составных частей, свойства, характеристики и другие данные, необходимые для сборки (изготовления) и контроля. К электронным моделям сборочных единиц также относят электронные модели для выполнения гидромонтажа и пневмомонтажа.
Сборочный чертеж
Документ, содержащий изображение сборочной единицы и другие данные, необходимые для ее сборки (изготовления) и контроля. К сборочным чертежам также относят чертежи, по которым выполняют гидромонтаж и пневмомонтаж.
Чертеж общего вида
Документ, определяющий конструкцию изделия, взаимодействие его составных частей и поясняющий принцип работы изделия.
Теоретический чертеж
Документ, определяющий геометрическую форму (контур) изделия и координаты расположения составных частей.
Габаритный чертеж
Документ, содержащий контурное (упрощенное) изображение изделия с габаритными, установочными и присоединительными размерами.
Электромонтажный чертеж
Документ, содержащий данные, необходимые для выполнения электрического монтажа изделия.
Монтажный чертеж
Документ, содержащий контурное (упрощенное) изображение изделия, а также данные, необходимые для его установки (монтажа) на месте применения. К монтажным чертежам также относят чертежи фундаментов, специально разрабатываемых для установки изделия.
Упаковочный чертеж
Документ, содержащий данные, необходимые для выполнения упаковывания изделия.
Схема
Документ, на котором показаны в виде условных изображений или обозначений составные части изделия и связи между ними.
Электронная структура изделия
Документ, содержащий структуру изделия (сборочной единицы, комплекса или комплекта) и другие данные в зависимости от его назначения.
Спецификация
Документ, определяющий состав сборочной единицы, комплекса или комплекта.
Ведомость спецификаций
Документ, содержащий перечень всех спецификаций составных частей изделия с указанием их количества и входимости.
Ведомость ссылочных документов
Документ, содержащий перечень документов, на которые имеются ссылки в конструкторских документах изделия.
Ведомость покупных изделий
Документ, содержащий перечень покупных изделий, примененных в разрабатываемом изделии.
Ведомость разрешения применения покупных изделий
Документ, содержащий перечень покупных изделий, разрешенных к применению в соответствии с ГОСТ 2.124.
Ведомость держателей подлинников
Документ, содержащий перечень предприятий (организаций), на которых хранят подлинники документов, разработанных и/или примененных для данного изделия.
Ведомость технического предложения
Документ, содержащий перечень документов, вошедших в техническое предложение .
Ведомость эскизного проекта
Документ, содержащий перечень документов, вошедших в эскизный проект.
Ведомость технического проекта
Документ, содержащий перечень документов, вошедших в технический проект.
Пояснительная записка
Документ, содержащий описание устройства и принципа действия разрабатываемого изделия, а также обоснование принятых при его разработке технических и технико-экономических решений.
Ведомость электронных документов
Документ, содержащий перечень электронных КД.
Технические условия
Документ, содержащий требования (совокупность всех показателей, норм, правил и положений) к изделию, его изготовлению, контролю, приемке и поставке, которые нецелесообразно указывать в других конструкторских документах.
Программа и методика испытаний
Документ, содержащий технические данные, подлежащие проверке при испытании изделий, а также порядок и методы их контроля.
Таблица
Документ, содержащий в зависимости от его назначения соответствующие данные, сведенные в таблицу.
Расчет
Документ, содержащий расчеты параметров и величин, например, расчет размерных цепей, расчет на прочность и др.
Эксплуатационные документы
Документы, предназначенные для использования при эксплуатации, обслуживании и ремонте изделия в процессе эксплуатации.
Ремонтные документы
Документы, содержащие данные для проведения ремонтных работ на специализированных предприятиях.
Инструкция
Документ, содержащий указания и правила, используемые при изготовлении изделия (сборке, регулировке, контроле, приемке и т.п.).
Better Tech Specs: Технический проект
Написание технического задания может показаться сложной задачей. Это может показаться слишком тяжелой работой или, что еще хуже, занятой работой, которая на самом деле не важна.
Но написание дизайн-документа не требует много времени и в идеале экономит ваше время в будущем. Вам даже не нужно знать, что вы собираетесь делать, прежде чем начать, так как написание дизайн-документа может быть отличным упражнением в «обдумывании написанного». В этой статье я расскажу о цели документа технического дизайна, элементах эффективного технического задания, а также о некоторых конкретных мыслях и примерах, которые помогут вам улучшить согласованность действий в вашей команде.
Какова цель технического проекта?
Целью документа технического проекта является помощь в критическом анализе проблемы и предлагаемого решения, а также информирование различных заинтересованных сторон о приоритетах, усилиях и воздействии.
Хороший проектный документ предупредит вопросы и запросы, которые могут возникнуть в процессе проверки кода, выявит крайние случаи и позволит людям предлагать улучшения до того, как будет проделана большая работа.
Примечание: Если дизайн-документ вызывает споры, это отличный сигнал о том, что следует провести личное обсуждение или что проблема не определена четко.
Загрузите бесплатную электронную книгу «Вопросы для команды инженеров-менеджеров»
Узнайте, как ледокольные вопросы могут помочь инженерам-менеджерам добиться согласованности, укрепить связи и укрепить доверие в своих командах. Включает 60 вопросов для разных этапов развития команды.
Вот шаблон для вашего следующего проектного документа
Трудно начинать с чистого листа. Я обнаружил, что хороший шаблон может ускорить процесс написания и побудит вас подумать над важными областями, которые могут не приходить в голову.
Каждый раздел в этой статье отражает раздел вашего проектного документа, это вариант технической документации, которую я написал в Google и передал команде инженеров в Medium. Вы можете обнаружить, что некоторые разделы не имеют отношения ко всем командам и проектам, поэтому используйте то, что полезно, а остальные отбрасывайте.
Конечной целью проектного документа является облегчение коммуникации и согласования, а не создание ненужной бюрократии.
Обзор
Начните сначала. Какую проблему ты пытаешься решить? Если вы сразу перейдете к решениям, людям будет трудно сориентироваться, что неизбежно приведет к рассогласованию и непониманию. Стоит потратить 2 или 3 предложения, чтобы эффективно установить контекст для вашей спецификации.
Затем кратко изложите предлагаемое решение. Этого должно быть достаточно для большинства людей, чтобы решить, следует ли им продолжать чтение, и оно должно быть понятно для тех, кто не знаком с проектом. Между несколькими предложениями и двумя абзацами должно быть достаточно.
Предыстория
Маловероятно, что при написании проектного документа вы впервые задумываетесь об этой проблеме. Справочная часть — это возможность ввести читателей в курс дела и поделиться своим контекстом в проблемной области.
Каковы мотивы проекта или дизайна? Есть ли какая-то историческая перспектива, которая поможет людям понять предложение? Кто-то пытался решить проблему в прошлом? Если да, то почему эти решения больше не подходят? Есть ли какие-либо другие вещи, которые повлияют на дизайн?
Цели, нецели и будущие цели
Для того, чтобы выстроить согласованность и передать определение того, что сделано, важно четко сформулировать цели этой работы. Лучшие цели — это простые, правдивые предложения, описывающие будущее состояние мира. В отличие от OKR, эти цели должны быть гиперконкретными.
Проекты часто имеют 3-5 целей.
Примеры:
- Горячее резервное копирование доступно в 3 регионах
- Данные деактивированных учетных записей автоматически удаляются через 30 дней
- Веб-интерфейс использует React вместо Vue
- Мобильные клиенты получают автоматические обновления
Нецели
Помимо объяснения того, чего вы хотите достичь, не менее важно указать, чего вы явно не касаетесь. Иногда их бывает трудно идентифицировать, но представьте, что другой человек может ожидать от этой работы.
Совет руководителям: Понимание взаимосвязанности работы — важная задача для инженерных групп — да и для всех команд, если на то пошло. Мы побеседовали с Пэтом Куа, опытным инженером-лидером и основателем Tech Lead Academy, который поделился: «Я часто просто предлагаю людям создать визуальную модель, например, что это за связи? Часто бывает очень полезно сказать, хорошо, эти вещи влияют друг на друга, они имеют такие результаты, и в итоге вы создаете сеть интересных взаимосвязей».
Для получения дополнительной информации ознакомьтесь с нашим полным чатом о времени выполнения заказов с Пэтом Куа о различных стилях технического лидерства.
Будущие цели
Будущие цели — это возможность перечислить то, что вы хотите сделать в будущем, но не включили в этот этап проекта. Другими словами, это то, что вы хотите убедиться, что ваше решение случайно не сделает его трудным или невозможным.
Рабочий проект
Это основная часть технической документации, а также самая разнообразная. В зависимости от проекта, размера вашей команды или количества заинтересованных сторон это может быть несколько абзацев или несколько страниц. Он часто будет содержать псевдокод, определения схемы или блок-схемы.
Вот некоторые общие вопросы, на которые можно получить ответы в рамках детального проектирования:
- Каковы требования пользователя?
- Какие системы будут затронуты?
- Какие новые структуры данных необходимы, какие структуры данных будут изменены?
- Какие новые API потребуются, какие API будут изменены?
- Каковы соображения эффективности (время/пространство)?
- Каковы ожидаемые схемы доступа (нагрузка/пропускная способность)?
- Как будут проверяться данные и каковы возможные состояния ошибки?
- Есть ли какие-либо потребности в регистрации, мониторинге или наблюдении?
- Есть ли соображения безопасности?
- Есть ли соображения конфиденциальности?
- Есть ли соображения по поводу мобильных устройств?
- Есть ли какие-либо особенности, связанные с Интернетом?
- Как будут тестироваться изменения?
- Как интернационализация и локализация — переводы, часовые пояса, юникод и т.
д. — влияют на ваше решение?
(Возможно, вам не нужно отвечать на все из них.)
Соображения третьих сторон
Сегодня принято полагаться на сторонние платформы для поддержки наших разработок, будь то часть AWS или GCP или отдельная служба. Стоит подумать о последствиях использования стороннего сервиса и предусмотреть потенциальные проблемы в будущем.
Стоимость этих услуг часто меньше, чем время инженера, но иногда она может неожиданно увеличиться. Быстро продумайте, как выставляется счет за услугу, и сделайте предварительный расчет того, что можно ожидать после полного развертывания услуги.
Несмотря на то, что вопросы безопасности и конфиденциальности были рассмотрены в детальном проекте, при использовании сторонних ресурсов есть определенные моменты, о которых следует подумать и которые необходимо указать.
Например, если третья сторона используется для выполнения операций с данными клиентов, она, скорее всего, будет считаться подпроцессором в соответствии с Общим регламентом ЕС по защите данных (GDPR). Итак, вам нужно дополнение по обработке данных? Вам нужно собирать и просматривать отчеты SOC2? Иногда клиентам требуется уведомление о новых подпроцессорах, что повлияет на приведенный ниже план развертывания.
Оценка работы
Для нетривиальных изменений предоставьте разбивку работы и задач. Сколько времени займет каждый этап? Какая работа может быть распараллелена? Какие существуют зависимости от других команд?
План развертывания
Необычно, что вы можете развернуть свой проект как одно изменение. В этом разделе обсудите, как необходимо поэтапно вносить изменения в модели и API. Будете ли вы постепенно внедрять свои функции для своих пользователей, используя флаги функций?
Обсудите свой обратный путь. Если что-то пойдет не так, как вы отмените часть процесса, оставив системы в работоспособном состоянии? Определите самые большие риски, которые вы видите, и объясните, как вы их обнаружите и снизите.
Альтернативные подходы
Недостаточно просто поделиться выбранным решением. Объясняя подходы, которые вы отвергли, вы можете сократить время обработки возражений со стороны других заинтересованных сторон и сосредоточить обсуждение на выбранном вами дизайне. Обязательно объясните, почему другие подходы кажутся хуже или не работают.
Также нередко в процессе проектирования появляется информация, которая повышает альтернативный подход к основному подходу. Если это произойдет, постарайтесь избежать заблуждения о невозвратных затратах.
Связанная работа
Существуют ли продукты — внутренние или внешние — похожие на этот проект? Сталкиваются ли другие команды с аналогичными проблемами?
Например, если вы создаете собственную базу данных NoSQL (😱), этот раздел может включать матрицу характеристик, сравнивающую ваши технические требования с существующими предложениями баз данных.
Будущая работа
Здесь вы можете помочь предотвратить потерю велосипеда и расползание прицела. Определите что-нибудь, что вы не решаете в этом конкретном дизайне, но что должно произойти в будущем или что было бы логичным продолжением проекта? Часто это более подробное описание будущих целей или, возможно, того, как некоторые нецели могут быть решены в будущем.
Когда вы напишете свой первый черновик, вернитесь и перечитайте его. Ставьте под сомнение каждое утверждение и решение. Если аргументация не ясна, добавьте дополнительные пояснения.
Подведение итогов
Я видел, как этот шаблон помогает разработчикам программного обеспечения всех уровней — я даже использовал его, чтобы продумать решение проблемы анализа данных, с которой мы здесь, в Range.
Я также видел, как люди негативно реагируют на идею документации технического дизайна, и, честно говоря, для многих команд и сред многие проекты на самом деле не нуждаются в технической документации. К сожалению, не существует жестких и быстрых правил, когда спецификация уместна. Это функция сложности, определенности и риска, и это то, что вам придется прочувствовать на себе.
Но в следующий раз, когда вы будете работать над сложной проблемой или жонглировать несколькими заинтересованными сторонами, попробуйте использовать этот шаблон и дайте мне знать, как это работает.
Вы можете найти меня в Твиттере @dpup.
Узнайте больше с помощью Lead Time
Lead Time Чаты — это незаписанные беседы с руководителями инженеров и другими влиятельными людьми в области технологий, которые ведет Джин Хсу (тренер по инженерному лидерству и вице-президент по инженерным разработкам на полигоне).
Вы можете просмотреть прошлые эпизоды в любое время в блоге Range, чтобы узнать о лучших методах поддержания продуктивности и связи вашей команды.
Для технических лидеров, которые ищут информацию и стратегии, которые помогут им в создании и управлении эффективными командами, мы также предлагаем информационный бюллетень «Время выполнения». Зарегистрируйтесь сегодня и получайте полезную информацию прямо на свой почтовый ящик.
Как писать документы технического проекта
TLDR
Техническая проектная документация (также известная как документация по техническому дизайну или техническое задание) — отличный способ создания подробных игровых планов для функций или решений технических проблем без написания кода. В конечном итоге они могут сэкономить вашей команде много времени.
Контур
- Важность документации по техническому дизайну
- Когда создавать документы технического дизайна
- Шаблон документа технического дизайна Mage
- Назначение
- Фон/контекст
- Требования
- Детальный проект
- План реализации
- Тесты
- Runbook
Важность документации по техническому дизайну
Документация по техническому дизайну — это инструкции по решению технической проблемы или созданию функции. Если у вас есть готовый вариант, его можно передать другому члену команды, который может быть менее опытным или незнакомым с рассматриваемой проблемой, и он все равно сможет решить проблему. Документы по дизайну могут выступать в качестве формы документации, на которую могут ссылаться другие члены команды.
Кроме того, процесс создания технического проекта заставляет вас продумывать крайние случаи и различные проблемы, с которыми вы можете столкнуться, и находить решения этих проблем. Этот процесс заставляет вас кодировать решения в вашей голове, поэтому, когда приходит время писать код, его выполнение происходит намного быстрее, потому что тяжелая умственная работа уже сделана.
Дизайн-документы должны создаваться в общей рабочей области (например, Google Docs или Notion), чтобы другие могли оставлять комментарии и оставлять отзывы. В результате дизайн-документы отлично подходят не только для делегирования работы и экономии времени, но и для совместной работы над техническим решением.
Когда создавать документы технического дизайна
Обычно хорошей идеей является создание документа технического дизайна каждый раз, когда вы пытаетесь решить техническую проблему, на решение которой уходит больше дня. Даже если для реализации решения требуется всего несколько часов, проектная документация все равно может быть полезна.
Тем не менее, проектная документация для большого проекта по сравнению с небольшой функцией, очевидно, будет немного различаться по длине. Дизайн-документ для небольшой функции может быть по сути псевдокодом, и это нормально, если он достигает цели документа. Главное, чтобы в дизайн-документе была цель, проблема, которую нужно решить, и решение. В дизайн-документе есть общие части, которые можно использовать в качестве шаблона, и мы подробно рассмотрим их ниже, но не все они должны быть включены в каждый отдельный дизайн-документ.
Проектная документация обычно не требуется для очень небольших функций или технических проблем с очень очевидными решениями, для реализации которых требуется мало времени. Это немного субъективно, но если дизайн-документ на самом деле не сэкономит вам много времени и преимущества его написания неясны, вам, вероятно, не нужно его писать.
Шаблон документа технического дизайна Mage
Разделы ниже каждого относятся к разделу шаблона проектной документации, с которого члены команды Mage начинают создавать новый проектный документ.
В верхней части документа необходимо указать имя автора и дату создания или последнего изменения документа. В Mage дизайн-документ часто пишется для одного или нескольких эпиков в Airtable, поэтому полезно включить ссылку на эпик Airtable.
Цель
Назначение описывает, что делает служба или функция. Постарайтесь уместить это в одно предложение.
Задний план
Зачем вам эта функция? Какую проблему ты пытаешься решить? В каком контексте другой член команды читает этот документ?
Требования
Какие результаты должна показывать эта служба или функция? Это могут быть такие показатели, как время отклика или характеристики компонента, созданного на основе внешнего интерфейса (например, адаптация к различным размерам мобильных устройств). Вы можете включить сюда пользовательские истории, чтобы описать требования.
Детальный дизайн
Это самая длинная часть проектной документации, требующая больших исследований, планирования и подготовки.