Стандарты и шаблоны для ТЗ на разработку ПО / Хабр
Введение
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.
ГОСТ 34
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
ГОСТ 19
“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
IEEE STD 830-1998
Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:
Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение
- 1. Назначение
- 2. Область действия
- 3. Определения, акронимы и сокращения
- 4. Ссылки
- 5. Краткий обзор
2. Общее описание
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователя
- 4. Ограничения
- 5. Допущения и зависимости
3. Детальные требования (могут быть организованы по разному, н-р, так)
- 1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2.
Интерфейсы аппаратного обеспечения - 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
- 2. Функциональные требования
- 3. Требования к производительности
- 4. Проектные ограничения (и ссылки на стандарты)
- 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
- 6. Другие требования
4. Приложения
5. Алфавитный указатель
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.
Мне же больше нравится адаптированный шаблон Карла Вигерса, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку вы уже несколько раз, надеюсь, перечитали.
ISO/IEC/ IEEE 29148-2011
Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.
Данный стандарт содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
• Software requirements specification (SRS)
System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов.
SyRS может содержать следующие разделы:
1. Введение
- 1. Назначение системы
- 2. Содержание системы (границы системы)
- 3. Обзор системы
- 1. Содержание системы
- 2. Функции системы
- 3. Характеристики пользователей
- 4. Термины и определения
2. Ссылки
3. Системные требования
- 1. Функциональные требования
- 2. Требования к юзабилити
- 3. Требования к производительности
- 4. Интерфейс (взаимодействие) системы
- 5. Операции системы
- 6. Состояния системы
- 7. Физические характеристики
- 8. Условия окружения
- 9. Требования к безопасности
- 10. Управление информацией
- 11. Политики и правила
- 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
- 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке
4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)
5. Приложения
- 1. Предположения и зависимости
- 2. Аббревиатуры и сокращений
SRS может содержать следующие разделы:
1. Введение
- 1. Назначение
- 2. Содержание (границы)
- 3. Обзор продукта
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователей
- 4. Ограничения
- 4. Термины и определения
2. Ссылки
3. Детальные требования
- 1. Требования к внешним интерфейсам
- 2. Функции продукта
- 3. Требования к юзабилити
- 5. Требования к логической структуре БД
- 6. Ограничения проектирования
- 7. Системные свойства ПО
- 8. Дополнительные требования
4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)
5. Приложения
- 1. Предположения и зависимости
- 2. Аббревиатуры и сокращений
Данный стандарт достаточно сложно найти в открытом виде в Интернете, но постараться можно, и опять же только на англ.
RUP
Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.
Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:
• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
1. Введение.
- 1. Цель.
- 2. Краткая сводка возможностей.
- 3. Определения, акронимы и сокращения.
- 4. Ссылки.
- 5. Краткое содержание.
2. Обзор системы
- 1. Обзор вариантов использований.
- 2. Предположения и зависимости.
3. Детальные требований
- 1. Описание вариантов использования.
- 2. Дополнительные требования.
- 3. Другие функциональные требования.
- 4. Нефункциональные требования.
4. Вспомогательная информация.
Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.
SWEBOK, BABOK и пр.
SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.
Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.
А как же Agile?
Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.
Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.
Заключение
Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.
Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
Также рекомендую ознакомиться со следующими материалами:
- Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
- Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
- Правила составления Software requirements specification (читать вместе с комментариями)
- Примеры ТЗ и другой документации по разработке АС для МЭР
- ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
- Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»
Инструменты для подготовки ТЗ + шаблон — Маркетинг на vc.ru
Подготовка технического задания — этап, на который уходит уйма времени и нервов. Еще больше сил уходит, если заказчик без опыта. При этом на ТЗ завязано все: срок, стоимость и содержание проекта.
9440 просмотров
Мы в Alto работали с десятками проектов и постепенно накопили список инструментов, которые помогали нам. В этой статье решили собрать их вместе. Надеемся, что они помогут вам оптимизировать процесс создания технического задания.
Содержание:
- User Story Mapping
- Прототипирование
- Структура сайта
- Хранение информации
- Сбор требований + шаблон
1. User Story Mapping
Разработка сайтов – это долго и трудоёмко. Поэтому вы должны быть уверены, что решаете правильную задачу. Если вы не понимаете кто ваш пользователь и чего он хочет – есть риск создать сайт, который не подойдет вашим клиентам. Именно поэтому работу над техническим заданием рекомендуем начать с «User Story Mapping».
Иллюстрация из книги «Пользовательские истории. Искусство гибкой разработки ПО»
В основе пользовательской карты лежат два инструмента: User Story и User Journey.
User Story – это короткие истории, которые объясняют роль пользователей на сайте. Обычно история описывает:
- роль пользователя;
- цель или желание;
- выгода.
Шаблон по которому строится User Story:
User Journey — описание задач и действий клиента на всех этапах взаимодействия с сайтом. Шаги пользователя продумывают, а затем фиксируют в удобном формате.
Список шагов может выглядеть следующим образом:
Зашел на главную страницу → открыл каталог → открыл карточку товара → перешел в другую карточку товара → добавил товар в корзину → оставил заявку.
Рассмотрим создание «User Story Mapping» подробнее. Опираться будем на рекомендации Джеффа Паттона из книги «Пользовательские истории. Искусство гибкой разработки ПО».
- Заведите аккаунт в miro.com. С помощью цветных стикеров создайте User Story для каждого персонажа.
- Опишите действия клиента по шагам.
Объедините шаги клиента в этапы.
Приоритезируйте действия пользователя внутри каждого этапа. Выделите релизы.
2. Прототипирование
Заказчик и исполнитель должны понимать, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа показать это.
Figma.com – это первый способ визуализировать то, что вы планируете сделать. Для его использования необязательно иметь навыки дизайнера. Можно примерно показать, как всё должно выглядеть.
Для творческого вдохновения, рекомендуем посмотреть раздел wireframes, где выложены сотни примеров.
Также вы сможете найти множество готовых макетов по запросу “UI kit figma”. Можно скопировать компоненты и собрать из них прототип.
Рекомендую обратить внимание на bootstrap UI-кит. Это поможет сократить расходы на реализацию проекта. Так как есть одноименная библиотека для разработки.
Miro.com – это второй способ визуализации. У этого сервиса есть библиотека, которая позволяет быстро создавать простые прототипы. Даже если у вас нет опыта в прототипировании.
Создавать прототипы в Miro почти так же просто, как на листе бумаги. Вам не нужно будет зацикливаться на деталях, что позволит сосредоточиться на концепте сайта.
3. Структура сайта
Если вы пишите техническое задание на разработку сайта, то вам не обойтись без подготовки структуры. Для этой задачи рекомендуем программу XMind. По ссылке можете скачать наш шаблон. Его хватит, чтобы приступить к работе над структурой сайта.
Структура сайта поможет определить основные страницы. Также она необходима SEO-специалистам для формирования семантического ядра – сбора ключевых слов
4. Хранение информации
Рекомендуем собирать всю информацию по проекту в Notion. Одной их его из особенностей – универсальность. Здесь можно вставлять чек-листы, создавать канбан доски, дорожные карты и многое другое. Он позволит иметь всё необходимое по проекту в одном месте.
Например, один из инструментов Notion – базы данных. Вы можете создать свою базу с кастомными полями. Добавить несколько видов отображения: в виде календаря или в виде таблицы. Это поможет программисту разобраться из каких сущностей состоит проект.
5. Сбор требований + шаблон
Специфика Alto — это разработка корпоративных сайтов от 100 до 400 часов и интернет-магазинов от 150 до 1200 часов. Если ваш проект планируется в этом же интервале, тогда этот шаблон может подойти вам.
Шаблон для разработки интернет-магазина.doc 503 КБ
Мы используем данный шаблон, как стартовый «конструктор» для составления более подробного ТЗ. Рекомендуем туда добавить раздел с планом работ и порядком приемки результатов.
Также рекомендуем посмотреть онлайн-генераторы, которые помогут собрать требования для технического задания:
- tz-online.site/write-tz/
- gagara-web.ru/tools/tz-generator/
В качестве дополнительных источников смотрите ГОСТЫ. Они громоздкие и избыточные, поэтому не подходят большинству проектов. Однако, в них можно найти такие требования про которые вы бы даже и не вспомнили.
- это еще советская разработка сбора требований для создания автоматизированных систем.
- стандарт разработки сложных систем. В нем есть вопросы о требовании к функциям, а также рекомендация: как описывать условия платформ, которые будут работать вместе с вашим продуктом.
- продвинутая спецификация для разработки требований к IT-продуктам.
Надеюсь, эта статья была вам полезна. Расскажите в комментариях, какие инструменты помогают вам. Ваш Alto!
Техническое задание (ТЗ) по управлению проектом Шаблон
Техническое задание (ТЗ) содержит изложение предыстории, цели и задач предлагаемого проекта. Шаблон ТЗ включает ряд критериев, необходимых для принятия стратегических решений по управлению проектом. Кроме того, в этом документе определяются виды деятельности, риски, бюджет и опыт, связанные с проектом.
В следующем шаблоне представлен обзор основных разделов технического задания по проекту. В этом руководстве я описываю определение и содержание ТЗ. Шаблон доступен для бесплатного скачивания в виде файла . doc.
Шаблон технического задания Скачать бесплатно
(файл DOC, 48Kb)
Техническое задание: определение и цель
В управлении проектами ответственность за каждый результат и сроки, в которые они должны быть завершены. В ТЗ указаны запланированные действия, типичные входы и выходы, бюджет проекта, рабочие графики и должностные инструкции. Он используется для оценки работы команды проекта, подрядчиков, консультантов, экспертов и других заинтересованных сторон проекта.
Цель ТЗ состоит в том, чтобы указать объем и тип работы для выполнения проекта. Кроме того, это руководящий документ, который устанавливает и определяет отношения между всеми заинтересованными сторонами проекта. Документ технического задания разрабатывается после определения, определения и планирования проекта.
ТЗ проекта содержит четкое описание следующей важной информации:
- обоснование обоснования реализации проекта.
- Предлагаемая методология управления проектами, а также рабочие планы и графики деятельности.
- Ожидаемые потребности в ресурсах , в первую очередь в отношении персонала.
- Отчетность правила и требования.
Что входит в ТЗ?
Разработка технического задания по проекту необходима для принятия решения о выделении необходимых средств на предлагаемый проект. Это результат процесса проектных предложений, и ТЗ служит основным отчетом этого процесса. ТЗ обычно требуется для:
- Предварительное ТЭО и анализ осуществимости
- Оценочная деятельность
- Разработка контрактов на реализацию и мониторинг
- Оценочные исследования
- Отчетность и аудит
- Прочие консультационные работы, перечисленные на любой стадии проекта, рассмотрение содержания 900 Техническое задание по проекту должно включать критически важную для бизнеса информацию, необходимую для начала, реализации и мониторинга деятельности по проекту. Между тем, точное содержание ТЗ варьируется от проекта к проекту и в значительной степени зависит от объема предлагаемого проекта.
- Предыстория проекта
- Цели проекта
- Вопросы, которые необходимо изучить и проанализировать в соответствии с определенными критериями Требования к отчетности
- План работы, включая графики мероприятий
- Опишите проект в контексте соответствующей деловой потребности
- Укажите общую роль заинтересованных сторон в выполнении проектной деятельности
- Выделите краткий обзор проекта на сегодняшний день
- Эффективность — этот критерий определяет, насколько хорошо данное действие преобразует имеющиеся ресурсы в желаемые результаты с точки зрения количества, качества и времени
- Актуальность — помогает проанализировать, выполняется ли данное действие выполнено с желаемой выгодой
- Эффективность – касается того, насколько широко были использованы результаты проекта и была ли реализована цель проекта.
- Воздействие – этот показатель помогает определить, в какой степени выгоды от проекта, полученные целевой аудиторией, оказывают общее влияние на большее количество людей заинтересованных лиц
- Устойчивость – этот критерий определяет, сохранятся ли положительные результаты проекта после окончания финансирования.
- Ключевые этапы процесса реализации проекта
- Требуемый уровень участия заинтересованных сторон, обеспечивающий бесперебойную реализацию
- Содержание и продолжительность деятельности и задач проекта
- Инструменты сбора информации, которые будут использоваться на протяжении всего проекта для целей мониторинга
- Правила анализа данных
- Тип работы, связанной с проектом
- Тип навыков и способностей, необходимых для выполнения работы по проекту
- Точное количество задействованных лиц, включая описание их квалификации, опыта и других профессиональных качеств
- Период участия каждого члена команды
- Описание обязанностей и ответственности каждого члена команды
- Взаимоотношения между членами команды, включая роли лидеров
- Содержание отчетов по проектам
- Правила составления приложений
- Шаблоны отчетов
- Язык отчетов
- Используемые компьютерные программы
- Даты представления
- Ответственные за отчетность Другая достаточная информация, такая как количество копий, которые необходимо создать, обязанности по составлению и представлению отчета и т. д.
- Анализ вопросов с точки зрения критериев оценки
- Предлагаемая методология реализации
- Требования к отчетности
- Финансовые ресурсы, выделенные для проекта.
- Обеспечить своевременное завершение всех результатов, в рамках стоимости и качества
- Обеспечить адекватное финансирование работы в соответствии с общим планом проекта/ресурсов
- Оценить риски и обеспечить принятие соответствующих мер по их снижению
- Решить все проблемы высокого уровня вопросы проекта, передача решения соответствующим группам управления по мере необходимости
- Выявление и анализ изменений, влияющих на проект, включая основные вехи, объем результатов, затраты и выгоды
- Обеспечение соответствия корпоративным политикам и протоколам, влияющим на проект
- Управление зависимостями проекта
- Взять на себя ответственность за локальные коммуникации по проекту
- Внесение/внесение вклада в критически важные решения Реализация решений «годен/не годен» тестирование, реализация и общение.
- Обзор хода выполнения проекта, вех, рисков и проблем
- Результаты для утверждения или решения, которые необходимо принять
- Особое внимание к специальным вопросам для обсуждения или эскалации
- AOB
Общий формат содержания Технического задания на проект предлагается ниже:
Обратите внимание, что это общие разделы шаблона ТЗ. Их можно изменить или опустить, в зависимости от масштаба конкретного проекта. Приведенное ниже описание разделов ТЗ является общим и представлено в качестве общего обзора в целях ознакомления. Это означает, что конкретный проект потребует более глубокого анализа контента, который будет включен в шаблон ТЗ. Когда вы планируете свой проект, вы должны сначала проанализировать и определить работы, которые должны быть переданы по контракту, а затем приступить к разработке технического задания по проекту.
1. Предыстория
Предыстория проекта предоставляет обзор истории проекта. В нем должно быть четко указано, зачем выполнять проект, и ссылка на контекст программирования. Цель состоит в том, чтобы предоставить читателю краткое объяснение необходимости проекта.
Раздел «Основные сведения» шаблона ТЗ обычно включает несколько параграфов, в которых рассматриваются следующие вопросы:
2. Цели
Целями проекта являются те желаемые достижения, которые могут быть разумно достигнуты после завершения проекта, с использование доступных ресурсов и в ожидаемые сроки. Они должны четко определять и определять, что ожидается от проекта и кто является целевой аудиторией.
В разделе «Цели» шаблона технического задания должны быть описаны желаемые достижения на разных этапах жизненного цикла проекта. В нем также должны быть указаны основные цели проекта, которые должны быть достигнуты после успешного завершения проекта. Вот пример того, как это должно выглядеть.
Тип работы/этап проекта | Общий объектив |
| – Завершение проекта | Увеличить продажи продукта «А» на 15% за 3 месяца |
| – ТЭО | Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия или отклонения предлагаемого проекта |
| – Мониторинг | Предоставить лицам, принимающим решения, достаточную информацию, необходимую для принятия обоснованных суждений о выполнении проекта |
| – Аудит | Чтобы проект оставался актуальным и обоснованным с юридической, экономической и технической точек зрения |
3.
ВопросыЛюбой проект включает в себя ряд вопросов и проблемных областей, которые необходимо решить для того, чтобы проект был реализован гладко. Проблемы являются предметом обсуждения или спора на протяжении всего жизненного цикла проекта. Они охватывают любую проблему, запрос, запрос на изменение или что-либо еще, что требует решения в ходе проекта. Нерешенные проблемы могут привести к провалу проекта.
В разделе «Вопросы» шаблона ТЗ должны быть выделены ключевые вопросы, которые необходимо изучить и обсудить на каждом этапе жизненного цикла проекта. Обычно ТЗ включает в себя ряд критериев оценки, которые следует использовать для анализа и решения проблем. Вот общие критерии оценки проблем для большинства проектов:
4. Методология
Методология реализации проекта обеспечивает набор общих принципов и правил, из которых будут выведены конкретные процедуры для определения того, как выполнить проект экономически эффективным способом. Описаны основные методы реализации проекта.
Таким образом, раздел «Методология» шаблона технического задания по проекту должен включать описание следующих элементов:
5.
ОпытОпыт, необходимый для выполнения проекта, определяет набор профессиональные требования к лицам и командам, участвующим в реализации проекта. Это станет основой для построения команды, включая обучение и оценку навыков.
В разделе «Экспертиза» шаблона технического задания на проект должно быть указано следующее:
6. Отчетность
Отчеты предоставляют ценную информацию о выполнении проекта за определенный период. Отчетность — это процесс, который начинается после запуска проекта и продолжается до тех пор, пока проект не будет завершен и его продукт не будет передан. Требования к отчетности будут определять, как писать и подавать отчеты по проекту и какую информацию включать.
В разделе «Требования к отчетности» шаблона технического задания должны быть четко указаны требования к процессу отчетности и могут быть указаны следующие сведения:
7. Рабочий план
Рабочий план — это своего рода стратегия, цель которой — помочь решить проблемы на протяжении всего проекта и повысить мотивацию и концентрацию сотрудников. Он определяет, какие действия необходимо предпринять, чтобы начать, реализовать и завершить проект в течение определенного периода времени и в рамках определенного бюджета. Он часто используется в качестве общего руководства для разработки плана реализации проекта.
В разделе «План работы» шаблона технического задания на проект должны быть указаны мероприятия и необходимые ресурсы, необходимые для достижения результатов и цели проекта. Поэтому он должен включать краткую информацию об ожидаемой работе и графике работы, которые основаны на следующем:
Подведение итогов
Техническое задание — один из важнейших документов, который следует учитывать в процессе управления проектом. Он определяет цель, объем, результаты и сроки проекта, а также возлагает на заинтересованные стороны ответственность за свои результаты.
Техническое задание [Бесплатный шаблон]
Пришло время для нового шаблона!
Бесплатный шаблон управления проектом в этом месяце является документом технического задания. Это действительно универсальный документ. Я использую его в основном для двух целей:
Во-первых, записывая в письменной форме, что на самом деле должна делать моя руководящая группа, чтобы установить «основные правила» для этой группы и их собраний. Это помогает им сосредоточиться на текущей работе, не слишком вдаваться в детали и помогает им и другим серьезно относиться к проекту.
Во-вторых, чтобы определить, что должен делать конкретный рабочий поток в проекте.
Это полезно, когда есть технический поток работы, который кто-то возглавляет, а другие направления подхватываются другими людьми. Это почти урезанная версия Документа об инициировании проекта или Устава проекта, поскольку он относится к определенному набору лиц и задач. Мне это нравится, потому что помогает им и мне увидеть, какова их конкретная роль и обязанности, входящие в их компетенцию.
Вы можете использовать это техническое задание (Word docx) для определения практически чего угодно: компетенции вашей школьной ассоциации родителей и учителей, условий клиентского проекта.
Все, что вам нужно, чтобы быстро подвести итоги высокого уровня результатов, целей, людей, затрат и временных обязательств, не углубляясь в детали, которые могут не иметь к ним отношения.
Зарегистрируйтесь для доступа к библиотеке ресурсов, чтобы загрузить этот шаблон.Что включено в техническое задание
Что входит в техническое задание? Я рад, что вы спросили.
Читайте дальше, чтобы увидеть, что я включаю.
Общая информация
Как и в случае со многими проектными документами, начните с общих сведений. Введите название проекта, название или идентификационный код. Добавьте сегодняшнюю дату. Поместите номер версии, чтобы версия была ясной.
Ваши метаданные готовы. Пока мы делаем такого рода обновления, не забудьте также добавить название проекта и имя файла документа в нижний колонтитул. Вы также можете добавить туда номер версии, если это имеет смысл (и если номер версии еще не указан в имени файла).
Я использую опцию «Вставить поле» в Word для ввода имени файла, но если оно выглядит слишком длинным или странным, я сокращаю его до имени, которое мы все поймем.
Введение в проект
Начните документ ТЗ по вашему проекту с краткого вводного текста о сути проекта.
Кратко опишите, что охватывает это техническое задание. Скорее всего, это будет либо компетенция одной группы, т. е. вашей руководящей группы, либо рабочий поток. Объясните, с чем это связано. Например:
Этот рабочий процесс охватывает технические элементы проекта xxx, включая программные и аппаратные элементы, техническое проектирование и тестирование.
Запишите все принципы, в рамках которых будет действовать настоящее техническое задание, например. Руководящая группа будет работать в соответствии с принципами PRINCE2®.
Цели и результаты
Укажите цели и результаты данного конкретного рабочего потока, проекта, группы и т. д. Вот несколько примеров целей проекта, которые вы можете адаптировать к своему ТЗ.
Вы можете увидеть, как описана работа, чтобы было ясно, какие результаты ожидаются, и мы разъясняем это в действительно очевидных терминах. У вас также будет некоторая конкретная информация о результатах, относящаяся к результатам, которые создает команда проекта.
Звучит много, чтобы рассказать об этом? Да. Но успешные менеджеры проектов следят за тем, чтобы команда точно понимала, чего от них ждут, и это один из способов добиться этого.
Ключевые ресурсы/роли и обязанности
Перечислите ключевые имена и то, за что они отвечают. Это легко сделать в виде таблицы.
Если вы используете шаблон ролей и обязанностей, вы можете сослаться на него вместо этого, чтобы не дублировать усилия и не записывать все это дважды.
В этом разделе я бы также добавил некоторую информацию о том, как часто команда собирается собираться. Например:
Встречи команды будут проходить ежемесячно или реже по мере необходимости. Депутаты допускаются только по согласованию с председателем. Постоянная повестка дня будет включать:
Структура организации рабочего потока
Следующим разделом вашего технического задания должна быть организационная схема. Это помогает людям понять, как этот рабочий процесс/команда/группа и т. д. вписывается в общий проект (или компанию). Это дает понять, как их действия влияют на общую картину.
Подход
Добавьте абзац или несколько маркеров, которые объясняют подход, который будет применяться для этого. Это объяснение того, как вы собираетесь достичь результатов, указанных выше.
Вехи
Вам не нужно предоставлять полное расписание проекта, но полезно включить таблицу с основными вехами или наглядную общую временную шкалу проекта.
Перечислите этапы и ожидаемые даты их завершения.
Никто не собирается использовать этот список в качестве основного плана проекта, но он существует в документе как часть настройки ожидания. Это точка обсуждения вашего согласия с ТЗ и возможность для команды установить реалистичные даты, прежде чем вы приложите слишком много усилий для составления надлежащего графика.
Бюджет
Если у этой работы или группы есть конкретный фиксированный бюджет, укажите его, чтобы они знали, с чем им предстоит работать.
Включите заявление вроде:
Ориентировочный бюджет для этого рабочего потока/группы составляет xxx. Это касается ХХХ. Бюджетные предположения включены в PID, а полные цифры подробно описаны в экономическом обосновании проекта.
Другие примечания
Наконец, добавьте что-нибудь еще. Создавайте новые заголовки, относящиеся к данному конкретному проекту, или способы работы, подходящие для вашей организации.
Старайтесь, чтобы документ был как можно короче, но если вам нужно добавить дополнительную информацию для пользы команды, сделайте это.