Вопрос глубины детализации технического задания (ТЗ) — это вечная дилемма в управлении разработкой 1С. С одной стороны, избыточно подробная постановка превращает постановщика в «ручного кодера», который просто пишет код словами, не оставляя разработчику пространства для маневра. С другой стороны, слишком общее функциональное описание рискует обернуться реализацией, которая совершенно не вписывается в архитектуру системы. В этой статье мы разберем по шагам, как найти золотую середину, проанализируем различные подходы и выясним, от чего зависит успех постановки задачи.
Проанализируем три основных подхода к составлению ТЗ, которые чаще всего встречаются в практике 1С-аналитиков и ведущих разработчиков.
1. Объектно-ориентированный подход («ТЗ-подарок»)
В этом случае постановщик полностью проектирует структуру метаданных. Он указывает: «Создать РегистрСведений с такими-то измерениями и ресурсами», «Добавить на форму документа РеализацияТоваровУслуг кнопку, по нажатию которой должен вызываться ОбщийМодуль».
Рассмотрим плюсы этого метода: разработчику не нужно «греть голову», он просто выполняет инструкции. Это идеально для начинающих программистов или аутсорсеров, работающих по фиксированной цене. Однако выясним причину, почему опытные специалисты могут саботировать такие задачи: если постановщик ошибся в архитектуре (например, выбрал РегистрСведений там, где нужен РегистрНакопления), программист все равно сделает по ТЗ, и ошибка вскроется только на этапе тестирования или эксплуатации.
2. Функционально-целевой подход
Здесь акцент смещается на то, ЧТО должна делать система, а не КАК. Мы описываем бизнес-процесс пользователя, необходимые проверки и ожидаемый результат. Например: «Система не должна давать отгружать товар, если задолженность клиента превышает лимит».
Разберем ситуацию: такой подход хорош для сильных разработчиков, обладающих аналитическим складом ума. Он позволяет программисту выбрать наиболее изящное решение (например, использовать МеханизмКритериевОтбора или ПодпискиНаСобытия). Минус — «испорченный телефон». Без четких рамок результат может кардинально отличаться от того, что представлял себе заказчик.
3. Архитектурный компромисс
Это наиболее сбалансированный вариант. Постановщик проектирует архитектуру (где создавать объекты, как они связаны), рисует макеты интерфейсов, но логику внутри процедур и функций оставляет на откуп разработчику. Рассмотрим пример описания события в таком ТЗ:
// Логика обработки проведения документа
1. Проверить наличие остатков по регистру "ЗапасыНаСкладах".
2. Если остатка недостаточно, выдать сообщение с указанием дефицита.
3. При успешной проверке сформировать движения:
- Расход по регистру "ЗапасыНаСкладах";
- Приход по регистру "Продажи".
Чтобы понять, готова ли задача к передаче в работу, проанализируем её через призму критериев INVEST. Если ваша постановка не соответствует хотя бы одному пункту, она считается «сырой».
Посмотрим на ситуацию с точки зрения пользователя. Интерфейс — это то, с чем человек взаимодействует 90% времени. Поэтому в постановке крайне желательно описывать динамическое поведение формы. Укажите, какие поля должны быть доступны только для чтения, какие — скрываться при определенных условиях (например, при выборе вида операции Переработка).
Особое внимание уделим Edge Cases (граничным условиям). Хороший постановщик всегда задает вопросы «а что если?»:
Товары указаны дублирующиеся строки?Выясним, как адаптировать текст в зависимости от того, кто перед нами. Люди разные, и это нормально.
Для «исполнителей»: Если программист склонен делать строго «от и до», не вникая в суть, нам придется использовать Вариант 1. Описываем всё: Индексировать ли измерения регистра, использовать ли Префиксацию номеров, в каком ОбщемМодуле разместить экспортную процедуру.
Для «архитекторов» и «эстетов»: Таких специалистов излишняя детализация раздражает. Им достаточно описать схему данных, бизнес-логику и ограничения. Например, достаточно указать: «Реализовать механизм контроля остатков через НовуюМетодикуПроведения». Все остальное они сделают в соответствии со стандартами 1С самостоятельно.
При написании ТЗ всегда придерживайтесь следующих правил, чтобы избежать двусмысленности:
Справочник.Номенклатура. Это исключит путаницу в базах с похожими объектами.Число (15, 2)) и проверку на отрицательные значения.Рассмотрим пример описания структуры нового регистра:
Объект: РегистрНакопления.ПродажиПоАкциям (Остатки)
Измерения:
- Акция (СправочникСсылка.Акции)
- Номенклатура (СправочникСсылка.Номенклатура)
Ресурсы:
- Количество (Число 15, 3)
- СуммаСкидки (Число 15, 2)
Подводя итог, проанализируем роль постановщика: это не просто «ретранслятор» желаний пользователя, а фильтр и архитектор. Ваша задача — перевести путанные слова заказчика («хочу, чтобы все считалось») на язык логических алгоритмов. Рассмотрим золотое правило: пишите ТЗ так, чтобы через месяц вы сами смогли его понять и проверить, а разработчик не бегал к вам каждые 15 минут за уточнениями. Помните о «проклятии знания»: то, что очевидно вам как бывшему разработчику, может быть совершенно неочевидно другому человеку. Всегда фиксируйте неявные допущения на бумаге.