Все нижеописанное является изложением моего собственного опыта и не является истиной в последней инстанции. Комменты, деление опытом – приветствуются!
Спойлер – идеального формата ТЗ нет.
За свой опыт работы я составлял и решил сотни задач по 1С и побывал в разных "шкурах" при их решении:
- как разработчик,
- как консультант,
- как организатор/менеджер,
- как заказчик,
- просто как наблюдатель
Я видел и задачи из одной строчки типа: "Сделайте нам, пожалуйста, чтобы финрезультат считался в 1С", и монструозные задачи оформленные по ГОСТ34 на 50 страниц убористого текста на внедрение системы учета чего-нибудь, как на скрине ниже.
Я понял, что нет идеального формата ТЗ для программиста, который гарантировал бы, что все будет выполнено все так, как вам хотелось бы.
Для маленькой задачи избыточное ТЗ может "сожрать" ваше время или ресурсы впустую, а на большую задачу/проект избыточное ТЗ заставит вас переписывать половину ТЗ потому, что новое требование, которое возникло или не было учтено, меняет множество спроектированных и описанных механизмов.
С другой стороны, по ТЗ "Сделайте мне все хорошо", тоже маловероятно достичь результата.
Тем не менее, я предлагаю использовать следующую структуру ТЗ. Из опыта, она проста и подходит для большинства задач с объемом трудозатрат разработчика в диапазоне от 1 до 50 часов.
Скачать шаблон технического задания для программиста 1с можно тут.
Кстати, на сайте interlogika.ru много интересных материалов по автоматизации.
Кратко пройдусь по некоторым важным пунктам правильного технического задания.
- Цель изменения
Пункт который раскрывает в контексте чего разработчику следует думать и принимать решения при выполнении задачи. Нарисовать кнопку это не цель, создать отчет тоже не цель. Попробуйте описать цель в виде результата от использования новшества.
Например: "Я перестану тратить время на сбор отчетов на 10 минут меньше в день" или "У меня появится информация, на основании которой я смогу принять решение и не терять товар стоимостью 1/10 от своих суммарных запасов" и т.п.
- Дано
Прям, как в задачке по физике . Тезисно о чем там писать указано в шаблоне. Цель – дать понять на уровне слов с каким техническим окружением и программами придется работать программисту.
- Что нужно сделать
Вроде бы, это есть сама суть ТЗ. Практически, чем более полно описать этот пункт и добить материалами, тем больше вероятность решения задачи так как вам хотелось бы.
Особенно обратите внимание на тезис "сценарий использования". Он похож на описание в виде userstories по agile методам и описания могут звучать примерно так: – "Я, как пользователь логист открываю монитор доставки, смотрю столбец таблицы тут, нажимаю сюда и т.д.". Очень хорошо дает понимание разработчику процесса использования дорабатываемого функционала.
- Как будет осуществляться проверка/сдача работ
Жирный пунктик о том, как будет проводится проверка и кем. Будем проверять на тестовой базе или сразу в продакшн запускаем. Если даже не описывать этот пункт, то хотя бы просто подумайте о нем, как это будет выглядеть.
Напоследок несколько скринов задач из моей системы учета задач.
