Разработка документации на создаваемые ИТ-продукты – это не только «правила хорошего тона», но и насущная необходимость. Ведь без технического задания невозможно зафиксировать требования к продукту, без руководства пользователя сложно грамотно продуктом пользоваться, без технической документации, описывающей продукт, сложно будет искать и исправлять ошибки и проводить необходимые доработки, когда в них возникнет необходимость, и т.д Обычно при разработке документации либо используют стандарты, описывающие требования к составу, структуре и содержанию документов (например, ГОСТ 19-й и 34-й серий), либо самостоятельно разрабатывают документ, создавая его на основе собственного опыта или по существующим образцам, в т.ч. взятых из интернета. С документацией, разрабатываемой в соответствии с ГОСТ, вроде бы, всё понятно – состав документов ясен, требования к структуре и содержанию определены, т.е. бери ГОСТ и пиши. С документацией, разрабатываемой вне стандарта, сложней – хорошо, если найдётся образец похожего документа (в т.ч. иногда берут за основу аналогичные документы из ГОСТ), но хуже, если такого образца нет. Тогда, при разработке документации, нужно определить: ·        Назначение документа (для кого он предназначен, для каких целей, когда и при каких обстоятельствах может быть востребован и т.п.); ·        Состав и форму представления информации, которая должна быть включена в документ (исходя из назначения документа); ·        Структуру документа (тут важно не только правильно структурировать документ, выделив разделы и подразделы, но и сгруппировать информацию по логически обоснованным блокам). А как потом из всего этого собрать документ? Лично я для себя взял за практику для любых документов делать синопсис. Синопсис – краткое изложение содержания произведения (книги, документа, статьи и т.п.). Независимо от того, «гостированный» ли это документ, или впервые разрабатываемый, я предварительно делаю синопсис, в котором выделяю несколько блоков: 1.      Общее описание документа, в которое включаю описание назначения (целевая аудитория читателей, цели документа, общая характеристика включаемой в него информации и т.п.); 2.      Примерную структуру; 3.      Описание содержания каждого раздела/подраздела, в т.ч. состав и форму представления информации, источники сведений для наполнения раздела и т.п. Третий пункт особенно полезен при составлении стандартных документов. Не всегда есть чёткое понимание того, что РЕАЛЬНО должно быть включено в данный раздел/подраздел. Чаще всего проблемы возникают с определением источников информации, на основе которой должен заполняться раздел – прямое указание в синопсисе этих источников позволяет заранее понять, где брать информацию, либо, если на момент написания синопсиса ещё нет ясности с источниками, можно поставить пометку «Требуется уточнить». Если же документ нестандартный, то синопсис просто становится спасением. Причём очень хорошей практикой (я лично таким методом пользуюсь) является предварительное согласование (или хотя бы предоставление для ознакомления) синопсиса с заказчиком – это что-то наподобие MVP, но в документации: документа ещё нет, но заказчик видит, что у разработчика есть чёткое понимание, что в документе должно быть, а в ряде случаев на этапе синопсиса могут появиться и замечания, и пожелания от заказчика. Синопсис можно делать как на отдельные документы, так и на весь предусмотренный проектом пакет. В таком случае я обычно делаю единый документ, в начале которого идёт перечень документов, разрабатываемых в рамках проекта, с указанием, на основе какого шаблона или стандарта они делаются, название, назначение, возможно – шифр документа и т.п. Резюме. Синопсис для технической документации, составляемый перед её разработкой – вещь крайне полезная, упрощает и ускоряет разработку документации и снижает вероятность ошибок и пропусков. Рекомендую взять на вооружение.