Как составить технико экономическое задание

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

В чем заключается технико-экономическое обоснование проекта

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

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

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

По сути, ТЭО – это более краткий и содержательный документ в сравнении с полноценным бизнес-планом.

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

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

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

Как происходит разработка технико-экономического обоснования проекта

Рассмотрим вопрос разработки технико-экономического обоснования проекта. Этапы разработки включают в себя следующие пункты.

• Резюме проекта.

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

• Обоснование.
  Собственно, само обоснование проекта – обоснованность выбора того или решения, технологии, материала, технических средств производства. Сюда же включаются возможные расчетные риски.

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

• Экономическое обоснование. Ряд расчетов, нацеленных на оценку результатов работы компании после внедрения предполагаемых нововведений.

• Выводы и предложения. Итоги, оценки, заключения.

Формат, в котором составляется технико-экономическое обоснование проекта, варьирует с изменением цели, которую он преследует:

• Получение кредита в банке для осуществления проекта;

• Принятие участия в государственных закупках (тендерах);

• Необходимость экономического развития предприятия, продиктованная руководством;

• Привлечение инвесторов;

Каким может быть технико-экономическое обоснование проекта (пример)

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

Для наглядности ниже приведены примеры ТЭО проекта, взятые из практики.

Пример № 1.

1. Проведение оценки реального состояния производства.

2. Результаты анализа рынка, проведение оценки производственной мощности предприятия.

3. Техдокументация.

4. Проведение оценки трудовых ресурсов.

5. Проведение оценки организационных и накладных расходов предприятия.

6. Оценка сроков реализации и существования проекта.

7. Проведение анализа финансовой привлекательности и экономической обоснованности проекта.

Пример № 2.

1. Описание идеи проекта, основ и принципов его реализации.

2. Проведение краткого обзора рынка, рассмотрение итоговых заключений проведенных исследований для ознакомления со спросом на новый вид услуги или новый продукт.

3. Описание технологических и инженерных составляющих проекта, таких как:

• процесс производства;

• обоснование потребности в обновлении старого оборудования или закупке нового;

• рассмотрение нового продукта с точки зрения действующих стандартов качества;

• анализ плюсов и минусов создаваемого продукта или услуги.

4. Описание финансовых и экономических показателей, включающих в себя:

• указание объема инвестиций для реализации проекта;

• указание возможных внешних и внутренних источников финансирования;

• указание предполагаемых производственных издержек.

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

6. Анализ восприимчивости продвигаемого продукта, услуги к нынешним рискам рынка и его устойчивость к возникновению рисков в будущем.

7. Анализ эффективности привлечения внешних займов.

Пример № 3

1. Описывается технико-экономическое обоснование в сокращенном варианте.

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

3. Проводится анализ рынка, исследованию подвергаются стандартные и пиковые производственные мощности компании-производителя и другие влияющие факторы.

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

5. Рассматриваются территориальные факторы, влияющие на расходы предприятия (стоимость участка земли, возможная арендная плата и др.).

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

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

8. Анализу подвергаются трудовые ресурсы, которые будут задействованы в новом проекте: количество работников различных категорий (рабочий, обслуживающий персонал, ИТР), их заработная плата и налоги, связанные с данными выплатами, возможный процент иногородних или иностранных работников предприятия.

9. Описываются сроки и этапы реализации проекта.

10. В общих чертах оценивается экономическая и финансовая состоятельность проекта.

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

Какие особенности имеет технико-экономическое обоснование проекта строительства

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

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

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

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

Часто реконструкция и/или расширение действующего производства более эффективны и рациональны, чем строительство новых объектов. При этом объем капитальных вложений будет меньше на 10-15 %. Для доказательства целесообразности реконструкции, расширения или возведения новых объектов с учетом общегосударственных интересов и при конкретных условиях следует применить подробно проработанное технико-экономическое обоснование проекта и его анализ.

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

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

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

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

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

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

Самые популярные показатели технико-экономического обоснования экономической эффективности проекта – это:

• Чистый приведенный доход;

• Дисконтируемый период окупаемости;

• Индекс доходности;

• Внутренняя норма доходности.

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

• Коэффициенты ликвидности;

• Коэффициенты рентабельности;

• Коэффициенты оборачиваемости;

• Коэффициенты финансовой устойчивости.

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

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

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

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

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

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

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

Как сделать технико-экономическое обоснование проекта производства

Технико-экономическое обоснование проекта производства – один из видов технико-экономического обоснования бизнес-проекта. Рассмотрим в качестве примера проект производства оборудования и изучим его особенности.

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

Ниже представлены аспекты проекта, которые обычно описывают в технико-экономическом обосновании производства оборудования:

• Внешние условия производства оборудования;

• Внутренняя среда, в которой будет проходить производство оборудования;

• Ресурсы производства (трудовые, финансовые, материальные и пр.), необходимые для внедрения проекта;

• Организационный план реализации проекта, в котором будет описано поэтапное создание производства;

• Прогнозирование финансовых показателей проекта;

• Риски, сопутствующие проекту, и методы сведения к минимуму их негативного влияния;

• Эффективность проекта с экономической точки зрения.

Технико-экономическое обоснование проекта для производства оборудования требуется для решения следующих поставленных задач:

• Перспективного планирования деятельности компании;

• Координации действий сотрудников;

• Проведения оценки финансовых показателей и рисков для демонстрации возможностей проекта потенциальным кредиторам и инвесторам.

Что учесть при подготовке технико-экономического обоснования инновационных проектов

Технико-экономическое обоснование и управление проектами, связанными с инновациями, ставят перед предпринимателем следующие основные задачи:

• Создание на предприятиях заказчика новых проектно-ориентированных структур управления;

• Регулирование правовых аспектов деятельности менеджеров по проектам;

• Внедрение в управление организацией современных информационных технологий и создание базы данных, содержащей все процессы инновационного проекта;

• Подготовка квалифицированных специалистов для управления инновационными проектами.

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

• Инвестирования в производственные фонды, имеющие продолжительные сроки амортизации;

• Вливания инвестиций в товарно-материальные запасы и иные оборотные активы для расширения производства;

• Вливания инвестиций в нематериальные активы (авторские и имущественные права, право на использование природных ресурсов и т. д.).

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

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

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

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

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

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

2. Методический подход к реализации технико-экономического обоснования проекта. Здесь определяются эффектообразующие факторы и выявляется информационный источник. Выбирается база для сравнения.

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

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

5. Формирование на основании сделанных расчетов и в целом анализа выводов по технико-экономическому обоснованию проекта.

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

Каких расчетов требует технико-экономическое обоснование ИТ-проекта

Информацию, используемую для проведения коммерческой оценки ИТ-проекта, делят на четыре основные группы:

• Доход от реализации;

• Текущие расходы;

• Инвестиции;

• Источники и условия, на которых ведется финансирование.

Рассмотрим более подробно структуру исходных данных, применяемых для оценивания инвестиционных ИT-проектов.

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

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

Выделяют два вида информационных технологий в зависимости от их влияния на финансовый результат компании:

• Информационные технологии, напрямую оказывающие влияние на финансовый результат компании;

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

Максимально точно можно выполнить расчет технико-экономического обоснования проекта для ИТ первого вида. Обычно подобные внедряемые программы связаны со снижением расходов по отдельным статьям (внедрение программ управления складскими запасами, бухгалтерских комплексов, ERP-систем).

ИТ второго вида – это программы финансового и маркетингового анализа, сайты, интернет-магазины, CRM-программы. На показатель дохода от их внедрения могут влиять: повышение качества решений, принимаемых управлением, рост количества потенциальных клиентов, улучшение качества работы с клиентами и прочее.

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

Группа «Инвестиции» содержит смету по капитальным расходам. Основываясь на данных о размере постоянных инвестиций, можно оперативно выполнить расчет амортизации.

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

Приобретение готового продукта («коробочного») включает в себя два простых блока расходов: «Стоимость приобретения программного продукта» и «Стоимость его внедрения».

В свою очередь разработка ИТ своими силами включает в себя следующие статьи расходов.

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

2. Единый социальный налог, который начисляют с оплаты труда.

3. Использующееся вспомогательное оборудование и программные средства.

Независимо от метода создания программного продукта организация несет дополнительные расходы, связанные с определенными статьями.

1. Обследование предприятия и формирование технического задания. Расходы на данный этап разумно оценивать по использованным в ходе процесса человеко-часам.

2. Реинжиниринг бизнес-процессов. Если бизнес-процесс является некорректным и устаревшим, то его автоматизация приведет только к обострению проблем на предприятии. В связи с этим при внедрении ИТ примерно 80 % действий связаны с построением новой, более успешной схемы работы и лишь около 20 % – с использованием инструментов, адекватных новым условиям. Расходы по проведению реинжиниринга можно оценивать как расходы на оплату труда специалистов (чаще всего это привлеченные консультанты).

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

4. Техническое оснащение. Внедрение новых ИТ предполагает в некоторых случаях усовершенствование технической базы (покупку новых серверов, прокладку сети, улучшение параметров рабочих станций).

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

Анализ технико-экономического обоснования проекта – неотъемлемая часть фазы проекта, предшествующей инвестициям. Если технико-экономическое обоснование проекта разработано в соответствии с предъявляемыми требованиями, это позволяет максимально точно рассчитать финансовое состояние организации, экономическую эффективность проекта, планы (производственный, инвестиционный, финансовый, организационный и план сбыта продукции).

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

Подготовка технико-экономического обоснования проекта требует изучения большого объема информации, которой у предприятия часто нет. Поэтому стоит обратиться к профессионалам. Наша информационно-аналитическая компания «VVS» является одной из тех, что стояли у истоков бизнеса по обработке и адаптации рыночной статистики, собираемой федеральными ведомствами. Компания имеет 19-летний опыт в сфере предоставления статистики рынка товаров как информации для стратегических решений, выявляющей рыночный спрос. Основные клиентские категории: экспортеры, импортеры, производители, участники товарных рынков и бизнес услуг B2B.

Наибольший авторитет наша компания завоевала в следующих отраслях:

• Коммерческий транспорт и спецтехника;

• Стекольная промышленность;

• Химическая и нефтехимическая промышленность;

• Строительные материалы;

• Медицинское оборудование;

• Пищевая промышленность;

• Производство кормов для животных;

• Электротехника и другие.

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

Узнать подробнее

Уточнить все детали можно по телефонам: +7 (495) 565-35-51 и 8 (800) 555-34-20 или просто заказать обратный звонок.

Заказать обратный звонок

Какой оптимальный размер ТЭО проекта?

Из каких разделов должно состоять ТЭО?

Что должна содержать описательная часть ТЭО?

Насколько детально нужно производить экономические расчеты для ТЭО?

Есть ли универсальные методики расчета ТЭО, позволяющие сэкономить время на подготовку следующих за первоначально разработанным ТЭО?

Любому руководителю финансово-экономической службы хотя бы однажды приходилось разрабатывать технико-экономическое обоснование (далее — ТЭО) разного рода проектов. И у многих из них в ходе разработки возникали вопросы:

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

Автор поделится с читателями собственным опытом разработки ТЭО проекта для создания нового предприятия в составе группы компаний.

Предназначение ТЭО и его отличия от других экономических планов и прогнозов

Прежде чем рассматривать непосредственно разработку и методику формирования ТЭО, кратко остановимся на предназначении ТЭО в практике бизнеса и его главных отличиях от других видов экономических планов и прогнозов.

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

По своей сути ТЭО является, конечно, разновидностью экономического прогноза на будущие периоды и стоит в одном ряду с такими документами, как:

• бизнес-план;
• бюджет доходов и расходов;
• прогноз финансового результата проекта;
• инвестиционный план.

В то же время ТЭО имеет несомненные отличия от этих расчетов:

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

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

Структура качественного ТЭО

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

1. Цель ТЭО проекта.

2. Анализ объемов реализации продукции/услуг проекта.

3. Описание проекта (участники, активы, использование доходов, порядок распределения прибыли и т. д.).

4. Сбытовая политика.

5. Описание хозяйственной деятельности в рамках проекта (бизнес-процессы и ответственные за их функционирование, технологическая цепочка, модель управления проектом и т. п.).

6. Источники финансирования проекта.

7. Финансовый план результатов проекта.

Для наглядности рассмотрим последовательность разработки ТЭО на примере проекта по созданию нового предприятия: два предприятия — ООО «ОПТторг» и ООО «Волга» — учреждают новое предприятие — ООО «Волгаторг».

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

Чтобы новое предприятие имело собственные оборотные средства и не прибегало к поиску внешнего финансирования, участники договорились, что сделают вклады в создаваемое предприятие в виде пяти розничных магазинов, на прибыль от работы которых будет финансироваться производственная деятельность ООО «Волгаторг».

А чтобы собственники предприятий-участников смогли убедиться в том, что проект выгодный, и нужно составить ТЭО.

Формируем ТЭО на основе указанных выше разделов.

1. Цель ТЭО.

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

Также в этом разделе целесообразно перечислить задачи, которые должно решить ТЭО. В нашем примере это:

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

После перечисления задач ТЭО можно переходить к составлению следующего его раздела.

2. Анализ рынка сбыта.

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

В нашем случае у нового предприятия два основных направления сбыта:

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

Чтобы составить прогноз розничных продаж, возьмем фактический среднемесячный оборот каждого магазина в отчетном 2019 г. (если, например, составляем ТЭО в октябре 2019 г., то за основу используем факт девяти месяцев) и спроецируем его на план 2020 г. Затем согласно динамике роста продаж в каждом конкретном магазине за последние несколько прошедших лет прогнозируем объемы продаж в 2021 и 2022 гг.

По производству овощной продукции планы на 2020–2022 гг. формируем на основе расчета потребностей в овощной продукции от розничной сети «Волга»

Прогноз реализации продукции и товаров нового предприятия в перспективе трех ближайших лет для ТЭО представлен в табл. 1.

3. Описание хозяйственной деятельности в рамках проекта.

Третий раздел содержит краткие пояснения о сути планируемой в рамках проекта деятельности его участников.

Что такое ТЗ?

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

Характерной особенностью технических заданий выступает сильная зависимость – как содержимого, так и оформления документа – от специфики конечного продукта. Отдельного упоминания заслуживают ТЗ на различное программное обеспечение, включая веб-сайты, онлайн-сервисы, интернет-магазины и различные приложения. Их актуальность особенно велика, что легко и вполне логично объясняется важностью и стремительным развитием IT-индустрии.

Для чего требуется ТЗ?

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

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

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

Кто должен составлять ТЗ?

Несмотря на кажущуюся простоту вынесенного в подзаголовок вопроса, ответ на него не так очевиден, каким видится на первый взгляд. Рассмотрим три возможных варианта.

Заказчик

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

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

Исполнитель

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

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

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

Совместно

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

Стоимость ТЗ

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

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

Как составить ТЗ?

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

Что потребуется?

Грамотно составленное ТЗ предусматривает наличие нескольких обязательных составных частей, включая:

1. Подробное описание целей реализации проекта.
2. Основные требования и ожидания от конечного продукта.
3. Ключевые этапы выполнения работ.
4. Календарный график или сроки исполнения.
5. Процедура контроля в процессе реализации проекта и итоговой приемки конечного продукта.
6. Приложения к ТЗ. Их перечень зависит от специфики проекта и обычно включает расчет стоимости, ссылки на нормативно-правовые документы и технические регламенты, другую справочную информацию, которая может оказаться полезной исполнителю.

Пошаговый план

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

Рекомендации по составлению

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

1. Однозначные формулировки. Содержание ТЗ не должно включать описаний или характеристик, допускающих неоднозначные трактовки. В тексте документа не допускается присутствие качественных прилагательных и крайне приветствуются конкретные цифры.
2. Определение используемых терминов. Заказчик и исполнитель должны разговаривать на одном языке. Поэтому ключевые понятия нуждаются в расшифровке.
3. Соблюдение установленных стандартов. Перечень нормативных документов, которые можно использовать при составлении технического задания, приводится ниже. Здесь же необходимо отметить, что ссылки на ГОСТы или ISO всегда полезны, так как сводят к минимуму возможные разночтения.
4. Предоставление исполнителю максимально возможной информации о заказчике. Такие сведения помогают сориентироваться в том, что является важным для заказчика, его целевой аудитории и других важных параметрах.
5. Перечисление конкурентов. Достаточно часто существенную помощь в реализации проекта оказывает изучение и анализ аналогов, уже представленных на рынке или запланированных к запуску конкурирующими компаниями. Такой подход к решению задачи заслуживает внимания, так как позволяет минимизировать сопутствующие расходы и не заниматься «изобретением велосипеда», а сосредоточиться на улучшении уже имеющихся разработок.
6. Внесение корректировок при необходимости. Если речь идет о сотрудничестве двух коммерческих структур, целесообразно наладить постоянное общение. В том числе –с целью уточнения ТЗ, если это потребуется. Хотя намного правильнее заранее прописать все возможные нюансы и сценарии развития событий, так как любые корректировки технического задания можно и нужно считать форс-мажором.

Скачать шаблон и пример ТЗ на оказание услуг – источник s-vfu.ru.

О стандартах

Порядок разработки технических заданий регламентируется множеством стандартов – как международных, так и отечественных. Причем в отношении разных проектов и продуктов действуют различные нормы. Наиболее часто упоминается международный стандарт ISO/IEC/IEEE 29148-2018. Он устанавливает требования к ТЗ на разработку информационных систем и программного обеспечения.

Если говорить об отечественных стандартах, необходимо обязательно отметить два из них. Первый – это ГОСТ 34.602-89, который устанавливает основные технические и другие требования к ТЗ на автоматизированные системы. Второй – это ГОСТ 19.201-78, определяющий порядок разработки ТЗ в рамках единой системы программной документации.

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

Существуют и другие стандарты, в большинстве своем международные – IEEE STD 830-1998, RUP, BABOK, SWEBOK и т.д. Их использования в отечественных условиях сильно ограничено из-за отсутствия учета местной специфики и широкого распространения.

Порядок документирования требований

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

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

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

В каком случае ТЗ не нужно?

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

Шаблоны для скачивания и примеры

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

FAQ

Что такое ТЗ?

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

Для чего необходимо техническое задание?

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

Что следует включить в ТЗ?

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

Кто занимается составлением ТЗ?

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

Какие типичные ошибки допускаются при разработке технического задания?

Самыми частыми ошибками при составлении ТЗ выступают: неоднозначные формулировки, отсутствие четких требований, недостаток информации о заказчике, продукте и конкурентах.

Подведем итоги

1. Техническое задание – это перечень требований к конечному продукту или результатам реализации проекта.
2. Разработка ТЗ – важный подготовительный этап, от успешного выполнения которого зависит эффективность дальнейшего сотрудничества между заказчиком и исполнителем, а также качество полученного на выходе продукта.
3. Составлением ТЗ занимается заказчик, исполнитель или одновременно оба. Последний вариант нередко оказывается самым плодотворным при условии взаимного доверия между сторонами.
4. Стоимость технического задания определяется индивидуально и зависит от специфики конечного продукта, его сложности и предъявляемых заказчиком требований.

Чтобы корректно определить задачи перед исполнителем, заказчик разрабатывает техническое задание. От правильности составленного техзадания зависит, будет ли удовлетворён заказчик результатом исполнения контракта. Разберёмся в основных вопросах, связанных с составлением технического задания для тендера.

Техническим заданием (ТЗ) называется документ, в котором описаны требования, предъявляемые заказчиком к товарам, работам или услугам. В ТЗ содержатся подробное описание и характеристики товара/работ/услуг и сроки поставки/выполнения/оказания.

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

Требования к техническому заданию законодательством не регламентируются, однако Федеральным законом от 5 апреля 2013 года № 44-ФЗ установлены чёткие правила к описанию объекта закупки. Согласно положениям указанного закона, ТЗ должно содержать показатели, с помощью которых определяется соответствие закупаемых товаров (работ, услуг) требованиям, установленным заказчиком (ч. 2 ст. 33). Кроме того, для этих показателей должны быть указаны минимальные и/или максимальные значения, а также значения, которые не меняются.

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

Как составляется ТЗ на тендер

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

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

• государственные стандарты;
• рекламу и каталоги;
• публичные оферты;
• исполненные контракты;
• официальные информационные источники уполномоченных органов и др.

Как правило, документ с ТЗ содержит таблицу с характеристиками. Указывая характеристики, необходимо учитывать нормирование. Предельные характеристики обозначены в специальном перечне товаров, работ и услуг (Постановление Правительства Российской Федерации от 2 сентября 2015 года № 927). На его основе заказчики формируют свои списки и устанавливают требования к количеству и наивысшей цене товаров, а также к их свойствам. Перечень характеристик зависит от категории товара.

Образец бланка для технического задания на тендер

Основное назначение технического задания — определить требования к объекту закупки. Согласно ч. 4 ст. 23 Федерального закона № 44-ФЗ, наименование закупки должно указываться в соответствии с каталогом товаров, работ, услуг (КТРУ), утверждённым Постановлением Правительства РФ от 8 февраля 2017 года № 145.

Если объект закупки присутствует в КТРУ, заказчик должен описать его, как это предусмотрено каталогом. Если описание закупаемой продукции отличается от описания в КТРУ, заказчик обязан включить в него письменное обоснование.

Требования к выполнению ТЗ заказчик формирует на основании правил описания объекта закупки (ст. 33 Федерального закона № 44-ФЗ).

При составлении ТЗ необходимо основываться на положениях 44-ФЗ, а также в обязательном порядке соблюдать нормы законодательства (гражданского, бюджетного, антимонопольного).

Чтобы составить техзадание по 44-ФЗ, можно разбить документ на разделы:

• общая информация;
• сведения об объекте закупки;
• требования к исполнителю заказа;
• условия исполнения контракта;
• приложения к ТЗ (на усмотрение заказчика).

Этапы составления техзадания

1. Подготовить список терминов, понятий и сокращений, используемых в документе.
2. Указать полную информацию о заказчике:
• наименование организации;
• адрес организации или подразделения, отвечающего за госзакупку;
• режим рабочего дня, согласно внутреннему трудовому распорядку.
3. В сведениях о закупке указать:
• если закупка совместная — права и обязанности каждого заказчика;
• если закупка централизованная — сведения об уполномоченном органе (ч. 1 ст. 26);
• в случае привлечения экспертов — порядок их работы.
4. Обозначить исходные условия, влияющие на процесс исполнения контракта. Указать справочную, производственную, опытную информацию по контракту. Например, уточнить время обслуживания закупаемой техники.
5. Указать информацию об особенностях производственного процесса или архитектурного объекта заказчика, влияющие на процесс исполнения контракта. Например, при составлении техзадания на закупку мебели указать, что при доставке потребуется поднять заказ на пятый этаж вручную в связи с отсутствием лифта.
6. Указать точное месторасположение объекта и его полное описание (при необходимости). Эти данные нужны, например, при проектировании инженерных коммуникаций или для того, чтобы точно рассчитать стоимость ремонта.
7. Определить нормативно-правовую базу (в том числе, по объекту закупки, условиям и срокам исполнения, гарантийным обязательствам) и установить требования по её соблюдению для участников.
8. Определить условия нормирования госзакупки (ч. 1 ст. 19), указать наименование и обоснование объекта госзакупки, дать его максимально точное описание (ст. 33).
9. Определить и указать экологические особенности объекта закупки.
10. Указать количество (объём) закупаемых товаров, периодичность, а также срок поставки.
11. Определить и указать гарантийный срок, уточнить, в каком объёме должны предоставляться гарантии.
12. Описать требования к упаковке и маркировке закупаемой продукции.
13. Определить эксплуатационные расходы.
14. Указать необходимость монтажа и наладки.
15. Определить порядок поставки и приёмки закупаемой продукции.
16. Указать на необходимость обучения (испытания) лиц, которые будут использовать объект закупки.

В данной статье я попытался подробно рассмотреть проблему разработки Технических заданий. Тема стара, как и проблема. Но она до сих пор часто решается “как получится”. Как сказал Генри Шоу “Мелочи тревожат нас больше всего: легче увернуться от слона, чем от мухи”.

О чем эта статья?

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?».  Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.  В процессе работы над статьей я понял, что уложить все в одной статье не выйдет, т.к. получится под 50 страниц и решил разбить ее на 2 части:  

• В первой части «Разработка Технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» я подробно попытаюсь ответить на вопросы темы, рассмотрю структуру и назначение Технического задания, дам некоторые рекомендации по формулировке требований.
• Вторая часть «Разработка Технического задания. Как формулировать требования?» будет полностью посвящена выявлению и формулировке требований к информационной системе.

Для начала надо разобраться, какой в действительности вопрос  интересует тех, кто спрашивает «Как разработать техническое задание?»  Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания.   О каких вариантах я говорю:

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной  IT-службы и решили поступить так: Заинтересованное лицо должно разработать Техническое задание и отдать его на разработку сторонней организации;
• Коммерческая организация решила внедрить у себя автоматизированную систему. Она имеет собственную  IT-службу. Решили поступить так:  разработать Техническое задание, затем согласовать его между IT-службой и заинтересованными лицами, и реализовать собственными силами;
• Госструктура решила затеять IT-проект. Тут все настолько мутно, куча формальностей, откатов, распилов и пр. Я не буду рассматривать такой вариант в данной статье.
• IT-компания занимается услугами по разработке и/или внедрению автоматизированных систем. Это наиболее сложный случай, ведь приходится работать в самых различных условиях:
  • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
  • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
  • Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
  • Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
  • Возможны и другие, реже встречающиеся варианты;

Думаю, сейчас у читателя должны возникнуть вопросы:

• А почему нельзя разрабатывать Техническое задание всегда одинаково?
• Существуют ли какие-то стандарты, методики, рекомендации? Где их взять?
• Кто должен разрабатывать Техническое задание? Должен ли этот человек обладать какими-то специальными знаниями?
• Как понять, хорошо составлено Техническое задание или нет?
• За чей счет должно оно разрабатываться, да и нужно ли оно вообще?

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли.  Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах.  Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

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

Что такое техническое задание?

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись.  Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели.  Возможно, кто-то сейчас подумал, что правда где-то по серединеJ. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что  в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации – далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

Куда более удачное определение представлено в википедии (правда про ТЗ в целом, а не только для программного обеспечения ): «Техническое задание – это исходный документ на проектирование технического объекта. Техническое задание устанавливает основное назначение разрабатываемого объекта, его технические и тактико-технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Задание как исходный документ на создание чего-то нового существует во всех областях деятельности, различаясь по названию, содержанию, порядку оформления и т. п. (например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д.)»

Отличное определение, полностью раскрывающее суть. Впрочем, требования ГОСТа направлены как раз на раскрытие этого определения. Я ни в коем случае не критикую требования ГОСТа, я просто утверждаю, что их там явно недостаточно, чтобы разработать эффективное Техническое задание. И это нормально, ведь есть ГОСТ, например, на изготовление хлеба, и это вовсе не значит, что любой человек может выпечь хлеб по ГОСТу. Кроме ГОСТа требуется знание методик и практик, как в любом деле. Именно этот факт лежит в корне проблемы, которая лежит посерединеJ.  А многие специалисты почему-то при необходимости разработать Техническое задание, обращаются только к требованиям ГОСТа. Ну, давайте начнем жить по ГОСТу, посмотрим, что получится! Но ведь не может такого быть, что в столь распространенном занятии, как разработка и внедрение автоматизированных систем  не проводилось исследований, не изучались практики, не писалось книг об этих самых практиках! И это так. Конечно, есть много отличных (!) трудов, посвященных тематике формулирования требований и в конце статьи я приведу такие примеры. Многое в своей практике я использовал именно оттуда, а когда работал над этой статьей, то тоже нашел много интересных мыслей, которыми рад буду поделиться. Так что, велосипеда изобретать не нужно, но есть потребность систематизировать эти знания. Кстати, любопытный факт, ни одного отечественного автора в этих трудах нет. Вся литература в переводе с западных авторов, но зато каких! Среди них есть просто виртуозы своего дела, у которых есть чему поучиться и нужно это делать. Иначе, споры о том, «Как разработать техническое задание» будут продолжаться бесконечно. Однако, я увлекся лирикой…

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования в функциональности;
• Требования к безопасности и правам доступа;
• Требования к квалификации персонала;
• …. И т.д. Вы можете  прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования.  Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома.  Красота!).  Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат  нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания.

Про виды требований я сказал, а что же со свойствами? Если виды требований могут быть различными (зависит от целей проекта), то со свойствами все проще, их 3:

1. Требование должно быть понятным;
2. Требование должно быть конкретным;
3. Требование должно быть тестируемым;

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

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

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание? 
• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
• А что такое техническое  проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

Так вот:

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

Технический проект – это документ, который предназначен для технической реализации требований, сформулированных в Техническом задании. Как раз в этом документе описываются структуры данных, триггеры и хранимые процедуры, алгоритмы и прочие штуки, которые потребуютсятехническим специалистам. Заказчику в это вникать вовсе не обязательно (ему и термины такие могут быть непонятны). Технический проект делает Архитектор системы (вот совмещение этой роли с программистом вполне нормально).  А точнее группа специалистов во главе с архитектором. Чем больше проект, тем и больше людей работает над Техническим заданием.

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований.  Что, знакомая ситуация?  И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между  ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично  это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени – это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.

Еще небольшой, но важный момент. Иногда Техническим заданием называют небольшой кусочек требований, простой и понятный. Например, доработать поиск объекта по каким-либо условиям, добавить колонку в отчет и пр. Такой подход вполне себе оправдан, зачем усложнять жизнь. Но применяется не на больших проектах, а на мелких доработках. Я бы сказал это ближе к сопровождению программного продукта. В этом случае в Техническом задании может быть описано и конкретное техническое решение реализации требования. Например, «В алгоритм такой-то внести такое-то изменение», с указанием конкретной процедуры и конкретного изменения для программиста. Это тот случай, когда граница между Техническим заданием и Техническим проектам полностью стирается, т.к. нет никакой экономической целесообразности раздувать бумаготворчество там, где это не нужно, а полезный документ создается. И это правильно.

Управленческий учет: с нуля до настройки в 1С, Excel и Google-таблицах

Уметь настраивать и вести управленку — значит быть полезным для руководителей. Научитесь понимать, откуда приходят и куда уходят деньги компании на курсе повышения квалификации от «Клерка».

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей  так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так  что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ.  Должен ли с ним знакомиться  Заказчик? Если хочет, почему нет, но настаивать  и утверждать данный документ нет никакой необходимости, он будет только сдерживать и  мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы  и программистами.

Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий.  По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания, а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично!  Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю?  Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

И так, ГОСТ рекомендует следующие разделы:

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приемки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

Итого, 9 разделов, каждый из которых тоже делится на подразделы. Разберем их по-порядку. Для удобства представлю все в виде таблицы по каждому пункту.

Раздел 1. общие сведения.

Раздел 2. назначение и цели создания (развития) системы.

Раздел 3. Характеристика объектов автоматизации.

Раздел 4. Требования к системе

Раздел 5. Состав и содержание работ по созданию системы

Раздел 6. Порядок контроля и приемки системы

Раздел 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Раздел 8. Требования к документированию

Раздел 9. Источники разработки

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

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

Во второй статье  будем говорить только о разделе 4 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

Почему требования должны быть понятными, конкретными и тестируемыми.

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

 

Надеюсь, идея понятна. Если будут конкретные вопросы, пишите, попробую помочь.

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

• Не следует использовать слов, имеющих множество синонимов. Если это необходимо, то лучше дать четкое определение термину в разделе «Термины и определения» к Техническому заданию.
• Следует стараться не использовать длинных предложений;
• Если какое-то требование Вам кажется слишком общим, его необходимо детализировать до более мелких, но конкретных требований;
• Используйте больше схем, графиков, таблиц, рисунков – так информацию воспринимается гораздо легче;
• Следует избегать таких слов: «эффективный», «адекватный», «простой», «понятный», «быстрый», «гибкий», «улучшенный», «оптимальный», «прозрачный», «устойчивый», «достаточный», «дружественный», «легкий» и др.  Перечень можно продолжать, но, мне кажется идея понятна (попробуйте его продолжить самостоятельно).

Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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