Техническое задание и Экспертиза ТЗ

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

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

• не полностью соответствует существующему документообороту в организации

• не отвечает всем требования законодательства или корпоративных стандартов 

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

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

Все эти моменты может проконтролировать документ «Экспертиза техничного задания».

Документ «Экспертиза техничного задания» должен проконтролировать следующие пункты:
• Правильность постановки задачи (отсутствие двусмысленных моментов)
• Оптимальность: предложенного технического решения разработчиком
• Отсутствие дублирования функционала
• Применимость полученного результат для решения поставленной задачи
Выкладываю реальные примеры документов ТЗ и Экспертиза ТЗ.

Пример ТЗ

Таблица 3. Соответствия колонок отчета и источников данных

Написать справку к отчету.

Интеграция

Отчет сохранить в базу УПП 2011: Внешние отчеты – Экономические –Товары на складах в суммовом выражении.

                Изменения созданы для конфигурации: Управление производственным предприятием, редакция 1.3 и Корпоративный менеджмент, редакция 6.2 (Версия 6.2.6.0). Используется в базе УПП.

Пример Экспертизы ТЗ

Экспертиза технического задания «Товары на складах в суммовом выражении»

Оценка постановки задачи

1. Из формулировки следует, что цель отчета – получить хоть какие-нибудь суммовые оценки складских остатков («Лишь бы не нулевые»).
2. При этом не конкретизируется, в каких случаях правильно использовать какой из указанных типов цен. («Какой будет»).
3. Не понятен экономический смысл подобной оценки.

Справка:

Все указанные три цены несут разную смысловую нагрузку:

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

2. «Закупочная (плановая)» равна средне-месячной цене закупки последнего месяца (считается ежемесячно). Имеет смысл для покупных материалов. Устанавливается на 01 число месяца.

3. «Плановая» (считается по закрытому месяцу). Для полуфабрикатов и продукции = себестоимости выпуска (упр. учет). Для материалов = Закупочной (плановой) из п.2. Устанавливается на последнее число месяца.

Оценка предлагаемого решения

Если принять постановку задачи, то предлагаемое решение:

• • Технически грамотное
  • Легко реализуемое
  • Не дублирует существующий функционал.

Прогнозируемые риски

1. Исходя из формулировки задачи, в случае, если для какой либо позиции номенклатуры была когда либо установлена «Административная цена» (даже 01.01.1980). То в дальнейшем будет использоваться только она (другие факторы на стоимость влияния иметь не будут).
2. Исходя из формулировки задачи, если когда либо, один раз, некий полуфабрикат (обычно выпускаемый нами), будет по производственной необходимости куплен у поставщика (или оформлен возврат «Обратной поставкой») — отныне и навеки в отчет будет попадать его закупочная цена.
3. Предложенная формулировка задачи приведет к тому, что согласно данным отчета, остатки на конец одного периода и остатки на начало следующего никогда не будут совпадать (из за разницы используемых цен в периоде).  Причем объяснить, откуда взялась эта разница (учитывая предыдущие два примера, будет очень сложно).

ВЫВОД:

Отчет сделать в требуемом виде можно, но его полезность – под большим вопросом.