В практике 1С-разработки термин «похабное ТЗ» обычно не имеет отношения к нецензурной лексике. Это профессиональный жаргон, описывающий документ, который невозможно использовать для качественной разработки. Разберем детально, что именно делает техническое задание (ТЗ) неприемлемым, как избежать конфликтов с руководством франчайзи и как научиться «переводить» пожелания клиента на язык программного кода.
Проанализируем основные маркеры, по которым опытные разработчики и руководители проектов определяют низкое качество документации:
кнопуля, суперкнопка или красивая форма, ТЗ теряет техническую точность. Разработчику непонятно, какой именно объект метаданных должен стоять за этой «кнопулей» — команда формы, кнопка на панели или гиперссылка.Документы, Справочники, РегистрыСведений или Отчеты, которые задействованы в процессе. Если написано «сделать отчет по продажам», но не указано, строить его по регистру ВыручкаИСебестоимостьПродаж или по регистру Продажи, это создает неопределенность.Рассмотрим по шагам, какую цепочку документов проходит задача в крупных проектах или профессиональных франчайзи. Это поможет понять, на каком этапе «хотелки» клиента должны превратиться в четкие инструкции:
1С:ERP или 1С:Бухгалтерии.Проанализируем ситуацию: если руководство франчайзи недовольно вашим ТЗ, значит, вы передали программисту «сырые» мысли клиента без технической обработки. Разберем, как это исправить. Вместо того чтобы писать «сделать расчет», опишем алгоритм программно. Посмотрим на пример правильного описания логики для кнопки:
// В ТЗ должно быть указано:
// 1. Объект: Документ.РеализацияТоваровУслуг
// 2. Действие: При нажатии кнопки "ПересчитатьСкидку"
// 3. Алгоритм:
// - Получить данные из РегистраСведений.ЦеныНоменклатуры на дату документа.
// - Выполнить проверку наличия остатка на Складе (РегистрНакопления.Запасы).
// - Рассчитать сумму скидки по формуле: Цена * Количество * ПроцентСкидки / 100.
// - Результат записать в колонку "Сумма" табличной части "Товары".
Важно помнить: ТЗ считается выполненным, если программист может реализовать задачу, не задавая уточняющих вопросов аналитику.
Выясним причину конфликта, описанного в теме. Если автор работает во франчайзи, его задача — быть «фильтром» между клиентом и кодом. Клиента не нужно «воспитывать» в плане терминологии, его нужно слушать, выявлять функциональные разрывы (FR) и самостоятельно преобразовывать его «кнопули» в технические термины.
Рассмотрим основные стандарты (например, ГОСТ 34.602-89), которые рекомендуют включать в ТЗ следующие разделы:
ДДС).Для того чтобы ваше ТЗ перестали называть «похабным», придерживайтесь следующих правил при его составлении:
Во-первых, всегда используйте терминологию метаданных 1С. Вместо «список сотрудников» пишите «динамический список справочника Сотрудники». Вместо «табличка» — «табличная часть» или «дерево значений».
Во-вторых, четко прописывайте формулы. Фраза «рассчитать налог согласно законодательству» — это плохое ТЗ. Правильное ТЗ содержит ссылку на конкретную статью кодекса или готовую формулу с указанием переменных.
В-третьих, используйте современные инструменты визуализации. Для описания бизнес-процессов отлично подходят диаграммы BPMN или простые блок-схемы. Для описания интерфейса — макеты (Mockups), но без фанатизма к цветам и размерам в пикселях, если это не критично для юзабилити.
В-четвертых, рассмотрите возможность использования языка Gherkin для написания приемочных тестов прямо в тексте ТЗ. Это позволит разработчику сразу понимать, как его код будет проверяться в Vanessa Automation или другими средствами автотестирования.
Мы проанализировали ситуацию и пришли к выводу: воспитывать нужно не клиента, а свой профессиональный подход к составлению документов. Если вы передаете разработчику «похабное» ТЗ (в значении «небрежное, некомпетентное»), вы рискуете тем, что задача будет понята буквально или выполнена с фатальными ошибками в архитектуре данных. Качественное ТЗ в 1С — это залог того, что система будет работать стабильно, обновляться легко, а ваша репутация как специалиста будет расти.