Рекомендации по составлению технического задания.

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

Любое ТЗ, должно давать ответы на три вопроса:

  • В какую именно конфигурацию 1С необходимо вносить изменения?
  • Какие показатели будут являться критериями успешности выполнения поставленной задачи?
  • Какие данные необходимо учитывать для успешного решения обсуждаемой проблемы?

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

Существуют основные моменты, которые помогут Вам составить грамотное ТЗ. Вот они:

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

В иных случаях, требуется составление ТЗ:

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

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

В качестве примера приведу реальный случай взаимодействия с клиентом. У клиента не получалось поставить товар в резерв. Он слышал, что такая функция есть, но у него не получается ее найти. Он хотел узнать, сколько будет стоить ему научиться пользоваться этим механизмом. Поскольку, клиент утверждал, что функция такая есть, я предположил, что у него конфигурация «Торговля и склад» (речь шла о 1C 7.7) и выставил ему символическую сумму. Когда все же выяснилось точное название конфигурации, оказалось, что клиент хочет механизм резервирования в Бухгалтерии, где его нет. Стоимость разработки механизма резервирования увеличилась примерно в 30 раз. Таким образом, какая именно конфигурация будет дорабатываться, оказывает непосредственное влияние на стоимость работ.

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


Рекомендации по составлению технического задания


Если такой информации нет, тогда в верхнем меню необходимо выбрать пункт «Помощь», а затем подпункт «О программе»:


Рекомендации по составлению технического задания


Появится окно с описание конфигурации:


Рекомендации по составлению технического задания


Для 1С 8.Х есть два вида интерфейса: «обычные формы» и «управляемые формы». Для обычных форм в заголовке программы присутствует вся необходимая информация:


Рекомендации по составлению технического задания


Если такой информации нет, тогда в верхнем меню необходимо выбрать пункт «Справка», а затем подпункт «О программе»:


Рекомендации по составлению технического задания


Появится окно с описание конфигурации:


Рекомендации по составлению технического задания


Для управляемых форм в заголовке программы присутствует вся необходимая информация:


Рекомендации по составлению технического задания


Если такой информации нет, тогда в верхнем меню необходимо выбрать пункт «Справка», а затем подпункт «О программе»:


Рекомендации по составлению технического задания


Появится окно с описание конфигурации:


Рекомендации по составлению технического задания


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

4) Старайтесь избегать в ТЗ при описании ключевых блоков и алгоритмов фраз: «примерно так». Это чревато увеличением как сроков разработки, так и стоимости доработок. Из практики: при наличии в ТЗ не совсем понятного описания бизнес-процессов, работает эмпирическое «правило ПИ» - сроки разработки сложного функционала увеличиваются в «ПИ» раз (3,14), соответственно будет увеличиваться и стоимость доработок.

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

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

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

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

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

В качестве примера(доработка 1С Бухгалтерия от Хьюмен Систем) приведу реальное техническое задание, которое было успешно выполнено, результат можно посмотреть здесь.

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