Как сделать описание проекта

Обновлено: 03.07.2024

Перечислить самые существенные компоненты описания проекта несложно. В этом документе официально объявляется о запуске проекта и назначении менеджера проекта. Также в нем обычно указывается номер счета, куда поступают выделенные на проект средства. Кроме того, содержится краткая аргументация задач последнего, то есть его обоснование.

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

Ограничения и предположения

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

Заинтересованные лица — кто они?

Необходимо в той или иной степени отметить всех заинтересованных лиц. Основное внимание, однако, должно быть направлено на ключевые фигуры из числа заинтересованных лиц. Проблема в том, как их выбрать.

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

После того как вопрос прозвучит десять раз, в распоряжении ведущего появятся от 70 до 90 карточек с ответами. Если группа подобрана хорошо (в том смысле, что в нее входят люди с различными точками зрения), вероятность того, что участники эксперимента укажут большинство заинтересованных лиц, весьма высока. Остается составить список названных персон и раздать его участникам для внесения изменений и дополнений.

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

Мы — сторонники следующего подхода. СПОНСОР должен подготовить описание, указав на одной-двух страницах, кем, что, почему, где, когда, как и за какие деньги должно быть сделано по проекту. В дальнейшем менеджеру или команде проекта предоставляется право в рамках планирования содержания проекта и определения этого содержания подтвердить или опровергнуть приводимые спонсором факты и предположения.

Ваша точка зрения позволяет поставить вопрос достаточно неожиданно: предположим, вы — менеджер проекта и числитесь в штате компании; имеете ли вы право наложить вето на реализацию проекта? В современном мире крупного бизнеса, где репутация менеджера определяется его последним проектом, следует ли вам браться за проект, если он, по вашему глубокому убеждению, обречен на провал? Некоторые исследования показывают, что менее 60% от общего числа проектов в сфере ИТ укладываются в смету, график и перечень требований, предъявляемых заказчиком. С составлением программы проекта дело обстоит получше — здесь успех сопутствует в 80% случаев. Впрочем, это тоже не ахти какое достижение.Со многим из вышесказанного я готов согласиться. Тем не менее считаю, что составлением описания проекта должен заниматься менеджер проекта, и никто иной.

Начнем с того, что для написания подобного документа спонсор должен обладать достаточно глубокими знаниями об управлении проектами в целом и о данном проекте в частности. Такие спонсоры — редкость, и уже поэтому разработка описания проекта — удел менеджера проекта.

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

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

Хотя фактическим автором описания является менеджер проекта, документ подписывает его начальник. Это необходимо в целях контроля за деятельностью менеджера проекта, а также согласования и утверждения документа всеми заинтересованными лицами. В число заинтересованных лиц, безусловно, входит и руководство компании — заказчика проекта.

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

Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.

Общаясь с большим количеством компаний, я все еще встречаю твердое убеждение в том, что написание технического задания для разработки ПО — пустая трата времени и денег. Мы в 65apps считаем иначе. Поэтому приведу несколько аргументов в пользу технической документации и расскажу, кто и как ее пишет.

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

Другой пример — государственные организации или организации, чья деятельность ограничивается или подчиняется законам и надзорным органам. Они обязаны осуществлять разработку ПО по всем правилам и с соблюдением всех стандартов. В таких проектах техническая документация, подготовленная по ГОСТам, — необходимое условие.
И разумеется, грамотно составленная и актуальная документация необходима для того, чтобы каждый участник в процессе разработки мог обращаться к документам, если возникают вопросы по конкретной задаче или по всей системе в целом.

Кто пишет техническую документацию

Обычно разработкой ТЗ занимается аналитик. Именно он общается с заказчиком / заинтересованным лицом и выявляет у него требования. В сложных случаях к процессу можно привлечь менеджера проекта, разработчиков, тестировщиков и других специалистов. Чем сложнее проект — тем больше требований к документации. Серьезные заказчики из крупных корпораций и госсектора требуют составлять документацию в соответствии с ГОСТами, а это задача очень трудоемкая, требующая внимательности к деталям и постоянной вовлеченности в процесс. И это не только ТЗ, но и технический проект, полностью описывающий все используемые в разработке решения, подходы и методологии. На него также распространяются ГОСТы. Подготовкой такой документации должен заниматься специалист — технический писатель.

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

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

Кто такой технический писатель

Строго сформулированного перечня должностных обязанностей технического писателя не существует: каждая компания формирует его сама, а иногда возлагает на такого специалиста и дополнительные задачи. Поэтому иногда бывает сложно даже определить род деятельности технического писателя. В нашей компании такой специалист составляет документацию, необходимую для дальнейшей разработки программного обеспечения.

Какая техническая документация нужна разработчику

Аналитик составляет ТЗ и согласует его со всеми заинтересованными сторонами. После того как собраны и утверждены все требования, можно приступать к созданию прототипов будущей системы и разработке программного обеспечения.

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

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

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

На этапе тестирования, помимо проверки работоспособности системы, проверяется также выполнение всех требований, зафиксированных в документах, что позволяет разрешить спорные ситуации с заказчиком.

Когда составлять техническую документацию

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

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

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

На сегодняшний день технический писатель не самая распространенная специальность, но для серьезной компании-разработчика такой сотрудник не менее важен, чем, например, аналитик.
Техническая документация обязательно разрабатывается для госзаказчиков, она необходима и для долгосрочных проектов, на которых с бОльшей вероятностью могут меняться подрядчики. Имеет смысл создавать технический проект для ноу-хау технологий и проектов высокой сложности — документация понадобится отделу QA, чтобы отличить баги и фич.

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

Вопросы

Основные вопросы, которые вам нужно себе задать:

• Зачем нужен этот проект?

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

• Что вы получите в результате выполнения проекта?

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

• Получите ли вы (нужно ли получить) еще какие-то результаты?

Из ответа на первый вопрос вы знаете, чего собираетесь добиться. Но достаточно ли этого? Возможно, есть что-то еще, что необходимо или стоит сделать в ходе выполнения основного проекта. Все это должно быть включено в описание проекта.

• Какие задачи специально выведены за рамки проекта?

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

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

• Есть ли в проекте какие-то упущения и не совпадает ли он в чем-то с другими проектами; возможен ли пересмотр рамок проекта?

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

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

• Из каких предположений (если они есть) вы исходите?

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

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

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

• я получу в свое распоряжение ресурсы, необходимые для достижения результатов в соответствующие сроки;

• дополнительные компоненты я смогу заказать у поставщика по существующим расценкам или дешевле;

• поведение потребителей в Лондоне будет строиться по той же схеме, что и в Бирмингеме, где мы уже предлагали эту услугу.

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

• Возможно ли появление серьезных проблем?

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

• Существуют ли какие-то особые условия, диктуемые заказчиком или обстоятельствами?

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

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

Ответы на перечисленные вопросы стоит занести в форму, которая послужит основой для описания проекта. Пример такой формы приведен в табл. 2.1.

Необходимо, чтобы информация была точной, полной, краткой и не допускающей разночтений. В описание включают только те сведения, которые вам нужны, чтобы судить о масштабе и сложности вашего проекта и начать планировать работу. Разве для этого требуется множество мелких деталей? Нет, потребность в деталях возникнет позже. Если вернуться к нашему примеру с ремонтом дома, на этом этапе вам не нужны сведения о цвете краски, которой вы будете красить стены, – эта информация никак не повлияет на решение о том, какие инструменты вы будете использовать, сколько времени это займет и в какую сумму обойдется ремонт.

Ниже я привожу три примера описания реальных проектов: 1) ремонт; 2) запуск нового продукта; 3) переоборудование офиса перед переездом на новое место. Как видите, проекты различаются объемом работ и уровнем сложности.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Составьте бизнес-план!

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

Описание реализации карточного проекта в банке на примере конкретного продукта

Описание реализации карточного проекта в банке на примере конкретного продукта Необходимость построения сбалансированной продуктовой линейки кредитных карточных продуктов. Стратегия развития бизнеса банка как определяющая основа построения продуктовой линейкиНа

Составьте план заключения

13 Экспертиза окончательной редакции проекта стандарта. Подготовка проекта стандарта к утверждению

13 Экспертиза окончательной редакции проекта стандарта. Подготовка проекта стандарта к утверждению 13.1 Общие требования к подготовке проекта стандарта к утверждению При получении окончательной редакции проекта стандарта национальный орган Российской Федерации по

Составьте инвентаризационный лист

Составьте инвентаризационный лист Больше всего я люблю прокрастинировать, жалуясь. Неважно, насколько разумны мои маленькие порции работы, я всегда могу найти причину пожаловаться, чтобы убедить себя отложить дело. Моя любимая жалоба: «Мне не хватает того, что нужно для

2. Составьте план интервью

Составьте план

Составьте план План необходим всегда, о чем бы ни шла речь. А лучший план – это соглашения о развитии, к которым вы приходите вместе с сотрудниками. Убедитесь, что ПЛАН оформлен как документ, что он соответствует целям карьерного роста сотрудника и удовлетворяет

Правильно составьте должностную инструкцию

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

Шаг 2.3. Согласуйте описание проекта с заказчиком

Шаг 2.3. Согласуйте описание проекта с заказчиком Если вы работаете на себя, то подготовка описания проекта не создаст вам особых сложностей. Конечно, потребуется какое-то время на обдумывание своих действий, и спешить тут не стоит. Описание должно быть тщательно

Шаг 3.5. Составьте календарный план

Шаг 3.5. Составьте календарный план Календарный план содержит даты начала и завершения работ по каждой задаче и соответственно даты начала и окончания проекта. Дату начала определяют следующим образом:• к этому дню должны быть завершены предшествующие задачи (вспомните

2. Составьте список нежелательных явлений

Составьте идеальную повестку дня

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

Составьте для себя памятку

Составьте для себя памятку С какими словами в умах ваших потенциальных клиентов ассоциируетесь вы? С какими словами должны ассоциироваться? С какими словами могли бы ассоциироваться, если бы реорганизовали и оптимизировали маркетинговые усилия компании?Представьте,

2. Описание проекта

Составьте карту

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

Составьте карту влияния

Составьте карту влияния Этот инструмент является наиболее эффективным, когда вам необходимо убедить в чем-то группу. Вы можете использовать его и в беседе с одним человеком.Если вы делаете презентацию перед аудиторией в 20 или менее человек, то вам необходимо составить

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

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

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

• научность — содержательный объем разработки, отвечающий требованиям науки;
• практичность — содержательный объем разработки, необходимый для ее практического использования;
• актуальность — потребность в разработке в определенное время;
• завершенность — степень готовности разработки для представления на экспертизу;
• конкурентоспособность — совокупность свойств инновационной разработки, удовлетворяющая общественные, производственные и корпоративные потребности и интересы в большей степени, чем у конкурентов.

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

Рис. 2.1. Инновационные свойства проекта

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

Структура пояснительной записки к проекту не типовая и определяется необходимостью, составом и объемом решаемых задач. Рассмотрим особенности ее вспомогательных элементов — аннотации и введения. Аннотация содержит лаконично изложенную основную идею проекта и его главный результат. Введение содержит обоснование и формулировку актуальности проекта, его цель и решаемые задачи для достижения цели. Может включать определение новизны и практического значения проекта как для разрабатываемого объекта, так и с точки зрения возможных социальных последствий от внедрения разработки.

Содержание разделов после введения начинается с изложения состояния ситуации на основе обзора известных данных по теме проекта с обоснованной формулировкой проблемы, цели и задач проектирования. Анализируются публикации по решению аналогичных задач, пути решения, результаты. Рассматриваются возможности использования результатов и выводов опубликованных работ для решения проектных задач либо пути собственных решений. Далее даются описания методик исследований и проектных работ по этапам проекта. Затем приводится теоретическая часть проекта с решением прикладных задач проекта. Характеризуются возможности проверки в эксперименте и применимости новых и известных теоретических подходов к объекту проектирования. В теоретической части приводятся модели, расчеты, алгоритмы, различные принципиальные схемы. Последующие разделы обусловлены содержанием конкретных проектов и могут включать, например, конструкторскую, технологическую, экспериментальную, экономическую части, материалы об испытаниях объекта проектирования, о внедрении в производство и на рынке сбыта и т.д. Желательно выносить в отдельный раздел материалы о практическом использовании результатов проекта, об организации и проведении мероприятий по внедрению практических рекомендаций; описание условий испытаний при внедрении; формы документов; акты внедрения; данные об апробации материалов (доклады, публикации), их использовании в хоздоговорах и программах.

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

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

Читайте также: