Введение

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

ТЗ может разрабатываться на систему в целом и/или на ее составные части.

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

1 Основные подходы к составлению ТЗ

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

1.        Совместная работа.

2.        Детальное описание результата.

3.        Механизм контроля за ходом проекта и квалификация консультантов.

4.        Согласование результата.

Гибкость.
1.1 Совместная работа
Лучше всего, если первый вариант технического задания (ТЗ) предприятие - заказчик составит еще до подписания контракта на внедрение системы автоматизации. В нем следует описать проблемы, которые необходимо решить в ходе внедрения, и определить желаемый результат. Затем при участии консультантов разрабатывается детальный план работ по реализации проекта в рамках конкретной автоматизации системы, уточняются способы решения поставленных задач, определяются критерии достижения целей проекта.

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

Пример:

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

Результирующие показатели проекта представляют собой следующее.

1.        Бизнес-модель вашей компании.

2.        Структура плана счетов

3.        Список необходимых документов (отчетов)

4.        Структура данных для генерации отчетов

5.        Структура аналитических кодов

6.        Описание структуры учетной модели в компании

7.        Описание результа работы и методов приемки

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

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

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

Структура данных для подготовки отчетов (описание источников данных для заполнения каждой строки отчета: субсчетов рабочего плана счетов и конкретных значений аналитических кодов и периода, из которого берутся данные).

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

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

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

Пример:

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

Пример:

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

Пример:

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






2 «Подводные камни»
У компаний, привлекающих консультантов для внедрения автоматизированных систем (АС), обычно, возникает довольно много претензий к их работе. Связаны они как с соблюдением сроков выполнения работ, так и с решениями предлагаемыми консультантами.

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

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

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

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

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

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

3.4 Перечень процессов

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




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

3.5 Цель процесса концептуального моделирования

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

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

Данный процесс может быть инициирован указаниями президента и правительства, изданием нормативно-правовых документов, или требованием заказчика АИС.

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

Оформление, согласование и утверждение концепции осуществляются в соответствии с:

a) законом Республики Молдова о нормативных актах Правительства и других органов центрального и местного публичного управления № 317-XV от 18.07.2003 г. („Monitorul Oficial al Republicii Moldova” № 208-210/783 от 03.10.2003 г.);

b) Постановлением Правительства о порядке проведения юридической экспертизы и государственной регистрации ведомственных нормативных актов №1104 от 28.11.1997 г. („Monitorul Oficial al Republicii Moldova” № 6-7/10 от 21.01.1998 г.).

3.6 Результаты процесса концептуального моделирования

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

a) определены цель и назначение моделируемой АИС;

b) изучены нормативно-правовая база, организационная структура управления и разработаны предложения по их актуализации;

c) определены функциональность, информационные объекты и потоки, пути интеграции с другими системами;

d) концепция оформлена, согласована и утверждена заказчиком.

3.7 Цель процесса прикладного моделирования

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

Описанный вариант программного продукта поставщик предлагает заказчику в виде бизнес–предложения, краткое содержание которого определено в приложении 1.

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

3.8 Результаты процесса прикладного моделирования

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

a) изучена предметная область;

b) определены и согласованы цели, назначение и основная функциональность программной системы;

c) разработан единый словарь терминов;

d) определены заинтересованные стороны, а также взаимодействующие организации и сторонние АИС;

e) определены бизнес-процессы и бизнес–роли программной системы;

f) разработаны предварительная архитектура программной системы и схема движения информации;

g) утверждены артефакты и передаются для дальнейшей работы.

3.9 Цель процесса определения требований заинтересованного лица

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

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

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

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

3.10 Результаты процесса определения требований заинтересованного лица

В результате успешной реализации процесса определения требований заинтересованного лица:

a) детализированы бизнес-процессы, определены бизнес-функции процессов и создана модель артефактов;

b) оговорены требуемые характеристики программной системы и инфраструктура пользователя, в которой она будет использоваться;

c) определены ограничения программной системы и ее элементов;

d) достигнута постоянная отслеживаемость требований заинтересованного лица;

e) определена основа для анализа требований к программной системе;

f) обеспечена основа для ведения переговоров и согласования поставки услуг или продукта.

3.11 Цель процесса анализа требований

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

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

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

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

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

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

3.12 Результаты процесса анализа требований

В результате успешной реализации процесса анализа требований:

a) утверждены модель бизнес-процессов и функциональность системы, а также установлены требуемые характеристики программной системы;

b) определены проектные ограничения и квалификационные требования к программной системе, а также требования к реализации проекта;

c) установлена основа для постоянного контроля реализации требований заинтересованного лица;

d) внедрена система управления изменениями;

e) обеспечена основа для адаптации инфраструктуры пользователя к требованиям программной системы;

f) определены требования к техническим средствам и сетевым решениям;

g) утверждены артефакты и переданы для дальнейшей работы.

3.13 Цель процесса структурного проектирования

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

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

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

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

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

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

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

3.14 Результаты процесса структурного проектирования

В результате успешной реализации процесса структурного проектирования:

a) определена архитектура программной системы и ее элементов;

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

c) проектное решение приведено в соответствие с взаимодействующими программными системами и элементами систем;

d) определена основа для проверки соответствия (тестирования) программных элементов;

e) определена основа для приобретения или сборки и интеграции программных элементов;

f) определена последовательность реализации функций программной системы;

g) утвержден технический проект.

Итоги

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

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

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