Тех зад. Правила технического задания
Многие компании не готовы привлекать подрядчиков на этап написания технического задания, полагая, что каждый подрядчик будет писать понятный только его сотрудникам документ, фактически гарантируя себе привилегированное положение на конкурсе\тендере.
Отчасти это действительно так, но связано подобное явление во многих случаях не столько с меркантильными интересами подрядчиков, сколько с различиями в подходе к реализации данного документа.
В определении технического задания на Википедии, в частности, говорится, что это «документ, содержащий требования заказчика к объекту закупки, определяющие условия и порядок ее проведения для обеспечения государственных или муниципальных нужд, в соответствии с которым осуществляются поставка товара, выполнение работ, оказание услуг и их приемка».
Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.
Однако, как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. К сожалению, многие заказчики уверены, что, написав пару страниц требований к будущей системе, они получат от нас точную (максимум с дельтой в 10-20%) оценку с календарным планом работ. Получая в очередной раз на почту «ТЗ, по которому к завтрашнему дню надо дать оценку и выслать КП», я всегда морально готовлюсь увидеть очередное творение в стиле «система должна обмениваться с сайтом всей необходимой информацией».
Одно время в отделе, где я работал, было принято следующее разделение: Техническим заданием назывался документ, описывающий требования к системе на понятном для бизнес-пользователей языке, а Техническим проектом – документ, составленный на основании Технического задания, более подробный, детально описывающий все функции, но уже на языке, понятном в основном разработчикам .
Мне данная характеристика, пусть и не являющаяся верной с формальной точки зрения, видится весьма справедливой для небольших компаний, у которых нет сверх бюджетов, но есть задачи, требующие срочного решения. Основным для них становится составление ТЗ силами своих сотрудников и его рассылка, к примеру, в несколько фирм-франчайзи. И естественно, что писать огромную простыню, содержащую неимоверное количество технической информации никто не будет.
Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?
Я не буду описывать основополагающие требования к структуре документа, такие как: в ТЗ должны быть описаны цели проекта, содержаться функциональные требования, должен присутствовать список сокращений и оглавление, написано все должно быть максимально простыми и короткими фразами и т.д. Считаю, это известно всем, кто хоть несколько раз читал технические задания.
Документы, с которыми мне приходилось сталкиваться, и на основании которых были получены максимально близкие к задумке результаты, обладали следующими свойствами:
1. ТЗ как инструкция . Документ по своей структуре напоминает инструкцию пользователя, где пошагово написано, в каком случае какие действия нужно выполнить пользователю, чтобы получить требуемый результат. Т.е. это были документы без сплошного перечня требуемых функций, но с логической разбивкой на отдельные процессы с описанием их специфики
2. Больше визуализации . Чем больше в документе содержится макетов\скриншотов\мокапов\блок-схем, тем меньше вероятность получить выполняющую вроде бы нужные функции, но обладающую совершенно иной логикой\оформлением\интерфейсом систему
3. Usability. Из двух предыдущих пунктов есть простое следствие – понятная логика работы и максимальная визуализация будущей системы помогут в итоге заложить в ТЗ нужное количество примечаний\пунктов, касающихся удобства использования системы. Для систем, с которыми работают низкоквалифицированные сотрудники, это может стать решающим фактором успешности проекта (впрочем, этот параметр также крайне важен и для топ-менеджмента, не желающего иметь дела с «этими бухгалтерскими программами»). Например, в ТЗ на систему для розничных продаж не указали, что поиск артикула должен занимать не более трех секунд. Если бы систему реализовали через типовой поиск конфигурации, то это могло привести к критическим ситуациям в реальной эксплуатации, т.к. с учетом количества номенклатуры этот поиск занимал до 30 секунд, что недопустимо при работе с розничными покупателями, где каждая секунда на счету.
4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.
5. Первичная обратная связь . Еще раз повторюсь - для успешной реализации ТЗ его не обязательно писать по ГОСТу. Не нужно писать документ, предназначенный только техническим специалистам. Техническое задание в первую очередь должно быть понятно коллегам его составителя, а потом и тем, кто будет его реализовывать. Крайне важно получить положительную обратную связь от коллег бизнес-пользователей, прежде чем направлять документ потенциальным подрядчикам или внутреннему отделу разработки. Документ, предельно ясный одному человеку, но не понятный даже ближайшему окружению не имеет шансов на успешную реализацию.
Безусловно, есть различные точки зрения на требования к составлению ТЗ. Однако в ситуации отсутствия должного количества времени, ресурсов и компетенций, именно написанное на максимально понятном для бизнес-пользователей языке техническое задание, обладающее указанными выше свойствами, будет иметь максимальные шансы на успешную реализацию.
Определение содержания проекта, разработка ТЗ
В данном разделе кратко рассмотрен вопрос разработки технического задания (далее ТЗ) . Вначале дано определение ТЗ, описаны преимущества ТЗ как для заказчика, так и для исполнителя, перечислены основные функции ТЗ. Далее рассмотрено, в чем же сущность ТЗ, раскрыты структура и содержание ТЗ, а также приведены примеры структуры ТЗ. В заключение, отмечены особенности ТЗ инновационных проектов.
Поскольку задачи разработки ТЗ инновационного проекта, имея свои особенности, в принципе остаются такими же, как при разработке любого ТЗ, то вначале рассмотрен вопрос разработки ТЗ в целом.
Определение
Следует отметить, что на данный момент времени нет стандартизированного определения технического задания (ТЗ) инновационного проекта. В актуальной базе национальных стандартов имеется три стандарта, имеющих отношение к ТЗ. Все они относятся к сфере информационных технологий:
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления.
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.
Например в «ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению» дано следующее определение ТЗ: «Техническое задание на автоматизированную систему - утвержденный в установленном порядке документ, определяющий цели, требования и основные исходные данные необходимые для разработки автоматизированной системы и содержащий предварительную оценку экономической эффективности».
В говорится, что ТЗ позволяет:
исполнителю - понять суть задачи, показать заказчику «технический облик» будущего изделия, программного изделия или автоматизированной системы;
заказчику - осознать, что именно ему нужно;
обеим сторонам - представить готовый продукт;
исполнителю - спланировать выполнение проекта и работать по намеченному плану;
заказчику - требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;
исполнителю - отказаться от выполнения работ, не указанных в ТЗ;
заказчику и исполнителю - выполнить попунктную проверку готового продукта (приёмочное тестирование - проведение испытаний );
избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний ).
Таким образом, техническое задание является документом, который содержит набор требований и позволяет как разработчику, так и заказчику представить конечный продукт и впоследствии выполнить проверку на соответствие предъявленным требованиям.
Чем подробнее будет составлено ТЗ, тем меньше спорных ситуаций возникнет между заказчиком и разработчиком во время приемочных испытаний.
ТЗ выполняет четыре основных функции:
Юридическая. ТЗ является юридическим документом, и в виде приложения включается в договор между заказчиком и исполнителем.
Организационная. С помощью ТЗ можно упорядочить дальнейшую работу, превратить ее в очередь (схему) заданий и не тратить усилий на ненужные действия.
Информационная. Грамотно составленное ТЗ может быть хорошим источником информации, необходимым для выполнения проекта. Структурированность ТЗ позволяет иметь информацию, которая действительно интересует, в той форме, которая легче всего воспринимается и в том количестве, которая необходима для выполнения работы .
Коммуникативная. Подробно составленное ТЗ помогает исполнителю лучше узнать потребности заказчика и выполнить работу, отвечающую всем его вкусам. Что также способствует процессу утверждения проекта.
Сущность ТЗ
Работа над ТЗ означает, что предполагается решение какой либо задачи и оно пошагово описывается в этом документе. ТЗ может быть разработано на что угодно: на создание технологии, нового материала, устройства, сайта, программы, стандарта, выполнение мероприятия и т.п.
Конечные результаты, полученные в ходе выполнения проекта, могут выступать в вещественной (материалы, процесс, технология), организационной (норма, стандарт), научно-технической и научно-методической (конструкторская документация, научно-исследовательский отчет, образовательная программа), нематериальной (патенты, монографии, статьи) и других формах.
Сущность ТЗ состоит в успешном выполнении поставленной задачи. Чем лучше и качественнее будет составлено ТЗ, тем эффективнее будет выполнена задача. Причем, это не зависит от ее масштаба. Неправильное составление ТЗ может иметь последствия, например непредсказуемость результата, работа будет выполнена не так как надо было заказчику или вообще не будет выполнена. Заказчик работы не получит того, чего хотел и имеет право не оплачивать сделанную работу.
Работа над ТЗ - сложный и ответственный этап, так как многие данные ещё не известны. Успех выполнения проекта по мнению специалистов на 50 -70% зависит от квалифицированного выполнения этапа разработки ТЗ.
Как правило, этапу разработки ТЗ предшествует проведение исследования предметной области, расчётов и моделирования.
Ответственная работа над ТЗ позволит его разработчикам увидеть сценарий выполнения задачи. Четко понять свои сильные и слабые стороны, как бы прожить процесс выполнения задачи. Определиться с критериями, задаться показателями, характеристиками, суммами, оценить ресурсы.
ТЗ согласуется с заказчиком или разрабатывается совместно.
Несмотря на свою важность, содержание и структура ТЗ практически не регламентирован нормативными документами.
Обычно заказчик задаёт цель (как он её понимает) и ресурсные ограничения (время, деньги). Задача исполнителя, прежде всего,- перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, осмыслить и уточнить исходные данные. В содержание ТЗ должны быть включены сведения, касающиеся целей и выполнения функций, реализующих заданные потребности, которые всегда увязывается с удовлетворением определенных требований.
Работа с требованиями подлежит управлению. Неопределенные требования вызывают неуверенность у всех участников работ, так как допускают различное толкование требований и не позволят объективно оценить качество разрабатываемого продукта.
При формировании системы требований необходим анализ доступности ресурсов, находящихся в распоряжении заказчика и разработчика: финансовые, производственные, людские, временные, а также учет требований надзорных и лицензионных органов, например, при проектировании технологических комплексов (производств). Наиболее часто контролирующими являются региональные органы Ростехнадзора, Росстандарта, Роспотребнадзора, Росприроднадзора, и др..
Ниже приведены примеры структуры ТЗ из различных источников.
Например ТЗ может содержать разделы :
предмет ТЗ;
цели проводимой работы;
требования к отчету;
порядок организации работы;
Пример из вышеупомянутого ГОСТ 19.201-78.
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.
Следующий пример ТЗ на оказание консультационных услуг
общие положения;
цель работы;
квалификационные требования к кандидатам.
Пример ТЗ на выполнение научно-исследовательской работы «Разработка концепции, стратегии развития и технико-экономического обоснования создания технико-внедренческого парка в г. Перми» (далее - НИР)
задачи НИР
исходные данные
основные требования к проведению НИР
календарный план выполнения НИР
предполагаемое использование результатов выполнения НИР
порядок сдачи-приемки результатов НИР
основание для выполнения НИР
исполнитель и соисполнители
Пример структуры шаблона ТЗ на выполнение НИОКР
Основание для проведения работы
Исполнитель
Сроки проведения работ
Цель выполнения работ
Результаты НИОКР
Разрабатываемая продукция
Технические требования
Основные параметры, которые должны быть достигнуты в результате выполнения работы:
Основные конструктивные требования (если применимо)
Требования по видам обеспечения (если применимо)
Требования по стандартизации, унификации, совместимости с сопрягаемыми объектами и взаимозаменяемости.
Требования по обеспечению безопасности для жизни и здоровья людей и охраны окружающей среды
Требования надежности (если применимо)
Требования по безотказности и долговечности.
Требования по эргономике и технической эстетике (если применимо)
Требования к эксплуатации, удобству технического обслуживания и ремонтопригодности (если применимо)
Требования к устойчивости к внешним воздействиям (если применимо)
Требования к эксплуатационным показателям (если применимо)
Требования по сертификации
Прочие требования и специальные требования по отраслям
Требования к патентной чистоте и патентоспособности
Требования к документации
Порядок приемки работ.
Таким образом, анализируя структуру в приведенных примерах можно отметить, что структуру и содержание ТЗ диктует та задача, которую необходимо выполнить.
Особенности разработки ТЗ инновационного проекта
Инновационные проекты – мероприятия уникальные, поскольку, связанны с трансформацией научно-технических идей в новые или усовершенствованные продукты, а также в новые или усовершенствованные технологические процессы, используемые в практической деятельности, либо в новые подходы к социальным услугам. Приходиться делать то, что никогда раньше не делалось. И прошлый опыт может лишь ограниченно подсказывать, чего можно ожидать. Поэтому инновационные проекты имеют высокую степень неопределенности и риска и в этом заключается их особенность.
Разработка инновационного проекта направлена на изыскание решений для получения намеченной конечной идеи проекта и создания комплекса заданий и мероприятий, которых будут связывать воедино время, ресурсы, и исполнителей для осуществления данного инновационного проекта. Любой инновационный проект при его реализации проходит определенный путь: от фазы разработки идеи до фазы неактуальности идеи. Стадия разработки ТЗ относится к начальному этапу инновационного проекта.
В инновационном проекте при создании совершенно нового продукта трудно запланировать заранее все параметры, поэтому предлагается использовать динамическое расширенное ТЗ, которое носит в основном, описательный характер.
Первым шагом после возникновения идеи нового продукта составляется каталог требований, в который могут включатся требования клиентов, сегментирование рынка для нового продукта, нормы, стандарты, общие цели (доля рынка, затраты), время выхода на рынок, длительность жизненного цикла, общая оценка рисков.
Показатели, очерченные в каталоге требований, конкретизируются в документе, который и называют расширенным техническим заданием.
Если каталог требований составляется на «языке клиентов», то расширенное ТЗ – на «языке предприятия». Расширенное ТЗ должно включать помимо традиционных пунктов (объем работ, отчетность, исходные данные, требования к параметрам и т.д.) и некоторые элементы бизнес-плана по проекту (предполагаемая политика ценообразования, планируемая доля рынка, планируемые обороты и т.д.).
Поскольку каталог требований создается, исходя из точки зрения клиента, язык для написания каталога требований выбирается также понятным клиенту (без специфических технических подробностей). В каталоге требований отражаются предложения предприятия в ответ на потребности клиентов.
В состав расширенного ТЗ могут включаются:
1. Описание проекта
2. Рыночные и экономические цели проекта
3. Временные параметры
4. Технические параметры
5. Производственные параметры
8. Требования к дизайну и эргономике
9. Нормы и предписания
Таким образом, основная задача составления расширенного ТЗ – в сборе наиболее полной информации о разрабатываемом продукте, от которой отталкиваются при планировании .
Информация расширенного ТЗ далее конкретизируется в плане структуры продукта, представляющего собой перечень всех компонентов, из которых будет состоять результат проекта. План структуры результата проекта содержит все компоненты, блоки, узлы создаваемого продукта.
Важнейшими элементами ТЗ являются: цель работы, область применения результатов, содержание работы, программа ее выполнения, технико-экономические и другие показатели, требования к работе уровню и способом ее выполнения, результаты работы, научная, научно-техническая и практическая ценность ожидаемых результатов; предполагаемое использование результатов и вид, форма представления отчетных материалов.
Рассмотрим местоТЗ в структуреинновационного процесса в организации (внедрение инноваций в организации) согласно .
Первоначально разрабатывается концепция инноваций. Которой предшествует этап исследований (обследование организации, выбор показателей эффективности её предстоящей инновационной деятельности, обоснование перечня мероприятий, необходимых для реализации инноваций). Концепция инноваций сформированной командой разработчиков разворачивается в задание (ТЗ) на разработку инновационного проекта, в котором должны содержаться все обоснования, исходные установки и параметры, необходимые для последующего проектирования.
Исходя из задания на разработку инновационного проекта, далее выстраивается подробный план мероприятий по разработке и решению отдельных задач, а также по контролю за их исполнением (контрольные точки по срокам, перечень контролируемых параметров, критерии контроля и т.п.). По сути говоря техническое задание, план мероприятия являются основанием для разработки инновационного проекта.
Содержанием проекта являются описание и регламенты плановых мероприятий, расчёты оптимальности расходования ресурсов, оценка предполагаемых результатов реализации, доведённых до количественных значений. Основой инновационного проекта являются его организационная и финансовая части. Далее следуют этапы адаптации и реализации проекта и анализ результатов проекта.
Когда ТЗ как документ утвержден, осуществляется планирование работ по проекту.
Тема 3.
ОПРЕДЕЛЕНИЕ ПРОЕКТА
Одним из наилучших способов удовлетворить потребности заказчика и основных заинтересованных сторон является использование интегрированной системы планирования и контроля проекта, для которой необходима селективная информация. Управляющие проектом, работающие над одним небольшим проектом, могут планировать и составлять графики выполнения заданий в отсутствие формальной системы планирования и информации. Однако в тех случаях, когда управляющий проектом должен руководить несколькими малыми или одним большим и сложным проектом, быстро достигается предел, за которым управляющий проектом больше не может справляться с деталями.
В данной теме описывается строгий, структурированный метод избирательного отбора информации для использования на всех стадиях жизненного цикла проекта с целью удовлетворения потребностей всех заинтересованных сторон (например, клиента, управляющего проектом) и для определения того, насколько выполнение проекта соответствует стратегическому плану организации.
Предлагаемый метод является своеобразным вариантом составления схемы проекта и поэтому называется структуризацией процесса работы. Начальные этапы разработки схемы помогают обеспечить выявление всех задач и убедиться в том, что все участники понимают, что от них требуется. Когда схема проекта и ее детали уточнены, можно разрабатывать интегрированную информационную систему для составления сетевого графика и распределения ресурсов. Эта же базовая информация будет позже использована и для контроля за ходом выполнения проекта.
Упорядоченный подход к сбору информации по проекту, необходимой для планирования, составления графика работ и контроля за выполнением проекта, обеспечивают пять типовых этапов. Эти этапы вместе с разработкой сетевых графиков проектов осуществляются одновременно, и обычно необходимо несколько повторений, чтобы разработать сроки и сметы, которыми можно будет пользоваться для контроля над проектом.
ЭТАП 1: РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ
Разработка технического задания (ТЗ ) готовит почву для разработки плана проекта. Техническое задание - это определение конечного результата или цели вашего проекта - товара или услуги для вашего заказчика. Основной целью здесь является как можно более четкое определение промежуточных результатов работы для конечного пользователя и концентрация (в единое целое) планов проекта. Хотя разработка технического задания является фундаментально важной, руководители проектов крупных корпораций с хорошим менеджментом часто поверхностно относятся к данному этапу.
Исследования показывают, что плохая разработка технического задания является наиболее частой преградой на пути к успеху проекта. Изучение проекта строительства большого нефтеперерабатывающего завода, проведенное Смитом и Таккером, показало, что плохая разработка технического задания и нечеткое определение основных составляющих проекта самым отрицательным образом сказались на его стоимости и графике работ. Пинто и Слевин доказали, что четкое определение целей больше, чем на 50% предопределяет успех на стадии формулирования концепции, планирования и выполнения проекта. Эшли и другие продемонстрировали, что у выдающихся, успешных проектов были четко разработаны технические задания и определены составляющие работы. Анализ Познера выявил, что, по мнению 60% респондентов-управляющих проектами, основной проблемой является отсутствие четких целей.
В ходе работы с более, чем 1400 управляющими проектами в США и Канаде Гобелай и Ларсон установили, что около 50% проблем планирования связаны с нечетким техническим заданием и постановкой целей. Все эти результаты указывают на прямую зависимость успеха проекта от четкого определения его ТЗ. Четкое ТЗ заставляет как заказчика, так и всех участников проекта концентрироваться на целях проекта.
ТЗ должно разрабатываться под руководством управляющего проектом и клиента. Управляющий проектом должен согласовывать с заказчиком цели, промежуточные результаты работы на каждой стадии проекта, технические требования и т.д. Так, например, промежуточным результатом на ранней стадии проекта может быть разработка документации; на второй стадии - три образца продукта; на третьей - значительное количество товаров для выпуска на рынок и, наконец, продвижение товара на рынке и обучение персонала.
Разработка технического задания на проект - это документ, который будет соответственно оформлен и использован владельцем проекта и участниками проекта для планирования и измерения успеха проекта. ТЗ объясняет, какую продукцию вы поставите своему клиенту по завершении проекта. ТЗ вашего проекта должно представлять намеченные результаты в конкретном и поддающемся измерению виде.
Очевидно, что ТЗ - это краеугольный камень, к которому привязаны все элементы плана проекта. Для того чтобы убедиться в правильности ТЗ, можно использовать следующий контрольный перечень:
Перечень вопросов по ТЗ:
1. Цели проекта.
2. Промежуточные результаты работы.
3. Контрольные точки.
4. Технические требования.
5. Ограничения и исключения.
6. Проверка выполнения работы совместно с клиентом.
1. Цели проекта. Первым этапом в определении ТЗ является определение основных целей для удовлетворения потребностей клиента. Например, в результате глубокого анализа рынка компания, занимающаяся компьютерными программами, решает разработать программу, способную автоматически переводить с английского на русский. Проект должен быть выполнен за три года при затратах, не превышающих $1,5 млн. Или такой проект - спроектировать и выпустить полностью портативную систему термической переработки вредных отходов за 13 месяцев при затратах, не превышающих $13 млн.
2. Промежуточные результаты работы. Следующим этапом является определение промежуточных результатов работы на протяжении всего жизненного цикла проекта. Так, например, промежуточным результатом работы на самой ранней стадии разработки проекта может быть список спецификаций. На следующем этапе это может быть испытание образцов. Последним этапом может быть окончательное испытание и одобренная программа. Промежуточные этапы работы обычно включают время, количество и/или оценки затрат.
3. Контрольные точки. Контрольная точка - это значительное мероприятие в процессе работы над проектом, которое происходит в определенный момент времени. График контрольных точек отражает только основные сегменты работы; он показывает первую, приблизительную оценку затрат времени, стоимости и необходимых ресурсов для проекта. Этот график составляется с использованием промежуточных результатов работы, как основы для определения основных сегментов работы и конечной даты. Например, испытания проведены и полностью выполнены к 1 июля этого года. Контрольные точки должны быть естественными и важными точками контроля. Они должны быть понятны всем участникам проекта. График контрольных точек должен установливать, какие основные подразделения организации будут отвечать за основные сегменты работы и обеспечивать проект необходимыми ресурсами и специалистами.
4. Технические требования. Обычно товар или услуга для того, чтобы хорошо работать, должны отвечать техническим требованиям. Например, техническим требованием к ПК может быть способность работать от сети переменного тока в 120 вольт или от постоянного тока в 240 вольт без адаптеров. Еще одним известным примером является способность системы 911 определить местонахождение и номер телефона звонящего.
5. Ограничения и исключения. Следует четко определить границы ТЗ. Невыполнение этого требования приведет к пустым ожиданиям и трате ресурсов и времени. Примером такого ограничения является сбор данных клиентом, а не подрядчиком; какой нужно построить дом, а не то, как он вписывается в пейзаж, или какие приборы, обеспечивающие охрану и безопасность, нужно установить; какие программы нужно ввести, а не какую подготовку дать персоналу.
6. Проверка выполнения работы совместно с заказчиком. Контрольный список вопросов ТЗ проекта заканчивается совместной с заказчиком проверкой выполнения работы. Основной проблемой является понимание и согласие заказчика с ожидаемыми результатами. Получает ли заказчик в виде промежуточных результатов то, что он хочет? Указывает ли определение проекта ключевые достижения, сметы, сроки и требования к выполнению работ? Рассматриваются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необходимо во избежание недопонимания.
Тесное сотрудничество с вашим заказчиком необходимо для разработки такого ТЗ проекта, которое бы удовлетворяло всем требованиям заказчика. Также хорошее ТЗ будет вам необходимо, если вдруг что-то начнет меняться. Четкое определение ТЗ проекта является необходимым условием для структурирования работ по этапам. ТЗ дает административный план, который используется при разработке вашего оперативного плана. ТЗ должно быть кратким, но полным; для малых проектов это обычно одна-две страницы.
©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16