Систематизация опыта подготовки технического задания

1. Зачем пишут ТЗ

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

Почему это нужно сделать?

Для этого существуют следующие причины:

1) Написание документов позволяет взглянуть на задачу «со стороны» потому, что при написании документ «отделяется» от автора и начинает жить своей самостоятельной жизнью. Автор и другие участники могут увидеть в замысле слабые места или пропущенные моменты.

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

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

4) Заказчику заранее важно увидеть, как будут тратиться его деньги.

В таблице ниже дано описание того, что дает ТЗ заказчику и разработчику:

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

1) Заказчик специально не устанавливает четких требований, чтобы потом бесплатно эксплуатировать разработчика «на скрытых работах» по своему разумению.

2) Разработчик надеется на постоянное продолжение работ за счет заказчика, аргументируя это некой неопределенностью.

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

2. Что пишут в ТЗ

2.1 Стандарты ТЗ

Форма и содержание ТЗ создается на основании установленных шаблонов. Это сокращает затраты, время и систематизирует работу. Как правило, для создания ТЗ используются следующие виды стандартов:

1) Международные стандарты

2) Государственные стандарты

3) Корпоративные стандарты

Кратко опишу стандарты, используемых для написания ТЗ:

Международные стандарты.

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

Государственные стандарты.

Основным стандартом для написания ТЗ по информационным системам является ГОСТ 34.602-89. Для крупных проектов, выполняемых в крупных компаниях, данный стандарт подойдет лучше всего. Иногда этот стандарт у ряда заказчиков является обязательным для применения на проектах внедрения автоматизированных систем управления (АС). Данный стандарт имеет более жесткую структуру, чем стандарт IEEE Std 830, что одновременно является его преимуществом и недостатком.

В большинстве проектов внедрения 1С:Предприятия данный стандарт является избыточным и сложным для понимания даже для разработчиков АС. Однако, когда разработка ТЗ всё-таки ведется по данному ГОСТу предлагается полностью сохранять структуру документа в соответствии с установленным стандартом. При этом по «пустым» разделам просто вносить комментарии типа: «По данному разделу требования отсутствуют».

Корпоративные стандарты.

Корпоративный стандарт существует на отдельном предприятии или в холдинге. Обычно корпоративный стандарт берет за основу любой из двух предыдущих стандартов и дорабатывается с учетом особенностей данного предприятия и его бизнес-процессов. В проектах внедрения 1С чаще всего используется корпоративный стандарт в виде упрощенного варианта ГОСТа34.

2.2 Разделы ТЗ

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

1) Описание целей и задач, которые должна решать информационная система (ИС);

2) Описание функциональных требований к ИС.

3) Описание процесса передачи ИС заказчику.

4) Описание сроков и стоимости работ.

Рассмотрим каждый пункт по отдельности.

2.2.1 Описание целей и задач

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

Раздел должен содержать в себе:

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

2.2.2 Описание функциональных требований к ИС

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

Понятие система включает в себя следующие составные элементы:

1) Если это программно-аппаратный комплекс (ПАК), тогда в систему входит:

• Платформа программы 1С:Предприятие;
• Конфигурация программы;
• База данных;
• Документация на ПАК;
• Рабочие станции;
• Серверы с серверным оборудованием;
• Внешнее оборудование (считывающие, передающие устройства и т.п.),

2) Если это автоматизированная система, тогда она включает в себя:

• ПАК;
• Пользователи, работающие с ПАК;
• Документация на АС;

2.2.3 Описание процесса передачи ИС заказчику

В этом разделе ТЗ описываются:

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

2.2.4 Описание сроков и стоимости работ

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

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

3. Как разрабатывают ТЗ

Процесс написания ТЗ можно разделить на следующие этапы:

1) Планирование работ;

2) Сбор информации;

3) Анализ и синтез информации;

4) Написание документа;

5) Согласование документа;

3.1 Планирование работ

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

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

3.2 Сбор информации

Существует несколько видов источников информации:

1) Методическая или техническая документация по данной задаче или аналогичной задаче, уже имеющаяся у заказчика;

2) Методическая или техническая документация по аналогичным задачам из других источников;

3) Проведение интервью с ответственными исполнителями заказчика;

Остановимся на процедуре проведения интервью с ответственными специалистами заказчика.

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

• Название проекта;
• Стороны проекта;
• Участников интервью;
• Время и место интервью;
• Вопросы для интервью;

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

3.3 Анализ и синтез информации

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

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

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

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

3.4 Написание документа

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

Правила написания технических документов рассматриваются на профессиональных сайтах технических писателей.

3.5 Согласование документа

Умение согласовывать готовый документа является не менее важным, чем умение разработать и написать этот документ. В соответствии с ГОСТ 34.602-89 предлагается следующий порядок согласования ТЗ:

1. Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки; тактико-технического задания и т. п.).

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

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

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

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

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

6. Согласование проекта ТЗ на АС разрешается оформлять отдельным документом (письмом). В этом случае под грифом “Согласовано” делают ссылку на этот документ.

7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

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

9. Копии утвержденного ТЗ на АС в 10-дневный срок после утверждения высылаются разработчиком ТЗ на АС участникам создания системы.

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемо-сдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии, с требованиями ГОСТ 2.501.

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

Для систематизации этого процесса предлагается установить следующие правила согласования ТЗ.

Перед началом согласования ТЗ разрабатывается документ «План согласования ТЗ». В Плане фиксируются участники, сроки, правила и форма согласования ТЗ. План обязательно следует подписать сторонами проекта. Форма согласования ТЗ должна включать в себя:

• ФИО участника;
• Должность или роль в проекте;
• Пункт ТЗ, по которому есть замечание;
• Описание замечания и предложения по его исправлению;

Процесс согласования должен проводиться по следующим правилам:

1. Согласование общей структуры документа (наличие всех необходимых разделов и групп требований);
2. Согласование детальных требований по разделам (полнота, точность определений, их непротиворечивость и т.п.);
3. Согласование формы написания документа (грамматика, синтаксис, пунктуация и правила оформления и т.п.).

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