В сфере IT-разработки, особенно в экосистеме 1С, где сроки поджимают, а требования меняются каждый день, качественное техническое задание (ТЗ) становится обязательным этапом, который помогает избежать путаницы и неопределенности в проекте. Но что же превращает ТЗ в действительно эффективный инструмент, а не просто формальный документ, который остается без внимания?
Рассказывает мой коллега Александр, аналитик 1С:
"В мире IT-разработки, особенно в экосистеме 1С, где сроки горят, а требования меняются ежедневно, именно качественное техническое задание (ТЗ) становится тем самым якорем, который удерживает проект от дрейфа в море неопределённости. Но что делает ТЗ по-настоящему рабочим инструментом, а не просто формальным документом, который никто не читает? Давайте разберёмся".
Введение
Прежде, чем перейти к теме разработки хорошего, качественного ТЗ, необходимо ответить на два вопроса: Кто такой системный аналитик? И зачем ему ТЗ?
Итак, системный аналитик в мире 1С — это не просто посредник между бизнесом и IT. Это переводчик, психолог и стратег в одном лице. Его задача — не только понять, чего хочет бизнес, но и выявить, что на самом деле нужно пользователям. Часто люди не могут чётко сформулировать свои потребности или боятся говорить о проблемах, которые мешают им работать. Задача аналитика 1С — услышать эти «тихие боли» и превратить их в конкретные, измеримые требования. Например, при автоматизации учёта в 1С:ERP аналитик должен чётко определить, какие модули будут задействованы: «Управление продажами», «Складской учёт», «Производство» — и как они будут взаимодействовать.
Техническое задание (ТЗ) в этом процессе — не бюрократический этап, а фундамент IT-проекта. От его качества зависит, будет ли результат соответствовать ожиданиям, уложится ли команда в сроки и бюджет. Часто проекты терпят неудачи не из-за плохого кода, а из-за размытых, противоречивых или неполных требований.
Именно качественное ТЗ позволяет:
зафиксировать договорённости между всеми сторонами;
создать чёткий план для разработчиков;
снизить риски недопонимания и бесконечных правок;
обосновать архитектурные и проектные решения.
Другими словами, ТЗ — это не просто список пожеланий, это материализованное понимание аналитиком задач бизнеса, а также основа для создания эффективного IT-решения.
Основываясь на методологии внедрения 1С, разберем структуру качественного ТЗ, которое станет надежным компасом для заказчика, менеджера, аналитика и разработчика.
Титульный лист.
Первое, на что стоит обратить внимание при оформлении и разработке ТЗ, это корректное заполнение титульного листа. Он должен содержать исчерпывающие данные для идентификации: от названия и версии проекта до даты и сведений об авторе. Особое значение имеет отметка о статусе, будь то первичный черновик или уже утвержденное ТЗ, так как он определяет степень готовности материалов и порядок дальнейшей работы.
Введение.
В данном разделе необходимо изложить ключевые задачи документа, определить круг заинтересованных лиц и границы применения представленных методик. Другими словами, это краткое резюме ТЗ: цель его создания, целевая аудитория (для кого он написан) и область применения (на какие работы распространяется). Например, проект направлен на автоматизацию учёта закупок в 1С:ERP через интеграцию с системой электронного документооборота.
Глоссарий.
Важным этапом подготовки качественного ТЗ является «Глоссарий». Даже если кажется, что все термины очевидны, глоссарий необходим. Он задаёт единый язык для всех участников проекта, предотвращает разночтения и минимизирует недопонимания.
Общие цели.
Качественная аналитика начинается не с макетов, а с понимания бизнес-контекста. В этом разделе аналитик декомпозирует проблематику текущих процессов и формулирует видение будущего решения. На этом этапе формируется фундамент ТЗ через ответ на вопрос «Зачем мы это делаем?». Работа включает глубокий анализ разрыва между текущим состоянием (AS-IS) и желаемым результатом (TO-BE).
Ключевой акцент — измеримость. Мы отказываемся от субъективных понятий вроде «повысить удобство» и фокусируемся на измеримых бизнес-метриках и жестких критериях успеха. Только четкие критерии (например, снижение временных затрат на операцию на 60%) позволяют объективно оценить эффективность внедренных изменений.
Границы и ограничения.
Здесь акцент смещается на методологию и теорию управления процессами. В данном разделе мы определяем, что система делать не будет. Другими словами, фиксируем то, что остается за рамками разработки. Это ключевой инструмент борьбы с бесконтрольным расширением («расползанием») требований, что позволяет сохранять фокус на главном. Сюда же входят внешние ограничения: законодательные, технические, бюджетные и временные рамки.
Функциональные требования.
Функциональные требования — это основная часть ТЗ, можно сказать, ядро. Эффективное ТЗ строится вокруг описания того, что должна делать система, оставляя вопрос «как» на усмотрение архитектора. Требования должны быть декомпозированы до атомарного уровня и легко поддаваться тестированию. Группировка требований по ролям или модулям системы помогает не потерять фокус, а использование формата «Система должна [действие] для [роль]» превращает сухой текст в понятный алгоритм автоматизации бизнес-процессов.
Описание реализации требований.
Как превратить абстрактное «что» в осязаемое «как»? Ответ кроется в разделе «Описания реализации». Этот раздел служит мостом между «что» и «как». Это своего рода дорожная карта.
Если функциональные требования отвечают на вопрос «что должна делать система», то здесь мы определяем каким образом эти требования будут реализованы технически. Важно не перегружать документ излишними техническими деталями, вместо этого следует сосредоточиться на ключевых архитектурных решениях, интерфейсах, технологиях и интеграциях, которые обеспечат выполнение заявленных функций.
Основная цель этого раздела — транслировать бизнес-логику в плоскость инженерных решений и дать разработчикам и архитекторам достаточно информации для проектирования системы, не ограничивая их творческий подход. Формат может включать таблицы, схемы взаимодействия или краткие описания модулей.
Сценарий тестирования.
Современная методология разработки рассматривает тестирование не как финальный аккорд перед релизом, а как сквозной процесс, закладываемый еще на этапе формирования требований. Такой подход позволяет нам сфокусироваться на проверке как функциональных возможностей, так и нефункциональных параметров системы в едином цикле.
В данной части ТЗ мы должны детально разобрать механизм проверки системы на соответствие заявленным характеристикам.
Ключевым принципом здесь выступает строгая прослеживаемость: каждый тестовый сценарий должен иметь прямую логическую связь с конкретным пунктом функциональных требований.
Чтобы обеспечить полноту покрытия, мы связываем каждый сценарий тестирования с конкретными задачами бизнеса. Практика показывает, что наиболее удобным инструментом для описания таких проверок является структурированная таблица. Сопоставляя шаги пользователя с ожидаемой реакцией системы, мы создаем понятную дорожную карту, которая служит надежным ориентиром как для инженеров по качеству, так и для заказчика.
Такой подход позволяет четко зафиксировать критерии успеха и минимизировать риск неоднозначных трактовок при приемке системы.
Моделирование и визуализация.
Действует принцип: одна схема заменяет тысячу слов. Сложные системы требуют визуальной ясности. Используйте диаграммы BPMN для отображения бизнес-процессов. Моделирование позволяет упаковать многостраничный функциональный анализ в единую логическую схему. Контрастное сравнение текущего состояния (AS-IS) и целевого образа (TO-BE) наглядно обосновывает ценность предлагаемых ИТ-решений и минимизирует риск недопонимания.
Выводы
В заключение хочется сказать, что хорошее, качественное ТЗ — это живой документ, который эволюционирует вместе с проектом, но его основа, заложенная на старте, остается неизменной. Инвестиции времени в создание четкого, полного и визуализированного технического задания — это не бюрократия, а главная страховка от рисков. Оно превращает субъективные «хотелки» в объективный реальный план, понятный всем сторонам, и является единственным беспристрастным арбитром в споре: «А договаривались ли мы об этом?».
Используйте компоненты и структуру своих ТЗ как чек-лист. Если каждый раздел вашего ТЗ будет содержать конкретные, измеримые и визуально подтвержденные данные, ваш проект с большой вероятностью ждет успех.
Как оценить зрелость команды 1С не по общему чек-листу, а по практикам, которые реально важны для платформы? Собрал модель из 8 направлений — от управления кодом и CI/CD до AI-практик — с конкретными критериями на каждом из пяти уровней. Внутри — открытый инструмент для самооценки.
Статья посвящена тому, как грамотное оформление и поддержание документации помогает сделать работу отдела прозрачной, предсказуемой и эффективной. Объясняем, как перестать тратить время на повторяющиеся вопросы, выстроить процессы так, чтобы сотрудники могли действовать самостоятельно, и превратить базу знаний в живой инструмент, а не в склад устаревших файлов. На конкретных примерах показываем, как простая документация экономит часы работы и снижает нагрузку на руководителя.
На примере записки по модели RLS в 1С ERP разбираю, что в таком документе уже хорошо, чего не хватает для управленческого решения и как сообщество оценивает качество такой аналитики?
Статья про то, как выстроить с Заказчиком прозрачные и доверительные отношения на всем пути — от коммерческого предложения до запуска. Покажем, как вовлекать его уже на этапе подготовки КП: делать документ вместе, чтобы было ясно, за что клиент платит и что в итоге получит. Разберем, как сбалансировать загрузку проектных команд и бюджет, выбирая подходы, которые не создают простоев и сохраняют темп. Также расскажем о том, как управлять ожиданиями с помощью стандартизированной документации и понятных результатов по каждому этапу. И, наконец, о том, как зажечь и удержать интерес пользователей.
При внедрении новых систем подготовка данных и нормативно-справочной информации часто становится источником рисков: результат не удовлетворяет стороны, а сроки и бюджет проекта оказываются под угрозой. Разберемся, как эффективно организовать этот процесс. Обсудим распределение ответственности между исполнителем и заказчиком, оптимальные сроки начала подготовки и методы ее организации. Расскажем об основах теории классификации для структурирования данных, а также о подходах к оценке затрат и управлению рисками. Статья поможет сформировать четкое понимание объема работ, зон ответственности и ожидаемых результатов на каждом этапе.
«Без хорошего ТЗ — результат такой себе». Но что делать, если ТЗ все время получаются плохими? Вместо того, чтобы заставлять заказчиков следовать шаблонам, мы применили концепцию обучения Дэвида Колба. В статье делимся опытом проведения 8 мастер-классов для 60 коллег по основам написания ТЗ, декомпозиции требований и описанию ошибок. Вы не получите волшебную таблетку, но узнаете конкретный план действий, который поможет сократить время анализа требований и улучшить коммуникацию в команде.
Система менеджмента качества уже много лет активно применяется в среде "1С-Франчайзи".
Но не все и не всегда используют ее на 100%.
Делюсь, как это делаем мы уже достаточно давно.
Организация ведения проектной документации на базе СППР. Как решить вопросы эффективности при проектах, направленных на доработку или внедрение новых продуктов от 1С, при "зоопарке" программ финансового учета и анализа, бухгалтерии ведения конструкторской документации и самое "любимое" это разработки, целые системы на 1С, которые не имеют документации.
Какую бы методологию не придумали - все отразить в ТЗ невозможно.
Отдельно стоит вопрос глубины проработки ТЗ аналитиком. Слишком детально - он уже чуть ли не знаниями архитектора должен обладать. Поверхностно - велики риски некорректной оценки времени исполнения.
Вопрос на подумать: нужно ли описывать в ТЗ ситуации по типу "если пометили на удаление справочник, то все связанные записи регистров должны удалиться при удалении через удаление помеченных" или "при распроведении документа список движений должен очищаться". Вроде это само собой разумеющееся, однако если это не будет реализовано - с кого спрашивать? В ТЗ же не было...
В целом в статье только общие вопросы, никакой конкретики.
Коллеги, приглашаю вас в проект, который родился на стыке двух, казалось бы, далёких миров: **инженерной строгости технического задания** и **логопедической точности коррекции речи**.
Мы разрабатываем **Chunk Advisor** — инструмент, который превращает разрозненные знания по 1С в "живые" инструкции для ИИ. И сейчас мы нашли пересечение, которое может заинтересовать каждого, кто пишет ТЗ.
### V2. Притяжение и отталкивание чанков
Мы поняли, что чанки (единицы знаний) ведут себя как части сложной системы: они либо *притягиваются* (если говорят об одном терминологическом поле), либо *отталкиваются* (если относятся к разным этапам или ролям). Это позволило нам создать математическую модель, где граф связей сам подсказывает, что можно дать ИИ в одном запросе, а что нужно разнести в разные промпты, чтобы не получить "кашу" из требований.
### V3. Логопедия ИИ
Но просто разделить недостаточно. Мы посмотрели на LLM как на ребёнка с нарушением речи. И применили логопедические методики:
- **Парафазии** (ИИ заменяет реквизиты на похожие) → мы лечим это чёткими терминами в "Гнозисе".
- **Аграмматизмы** (код синтаксически верен, но не работает) → мы исправляем это "Праксисом" с обязательными примерами и антипримерами.
- **Контаминации** (смешение нескольких требований) → мы лечим это "Цельностью" (один чанк — одна проблема).
### Почему это важно для тех, кто исследует правила ТЗ?
Потому что **промпт для ИИ — это и есть ваше техническое задание**.
Chunk Advisor V3 — это не просто база знаний. Это методология, которая заставляет ИИ:
1. **Диагностировать** проблему (как логопед ищет симптом).
2. **Следовать иерархии** правил (как в ТЗ есть "критические" и "второстепенные" требования).
3. **Учитывать границы** (то, чего НЕ делать, мы теперь выделяем весом 0.6 — это важнее описания того, что делать).
**Мы превратили размытый запрос "сделай удобно" в структуру ТЗ с измеримыми целями (AS-IS/TO-BE), глоссарием и сценариями тестирования.**
Если вам интересно, как сделать так, чтобы ИИ перестал "галлюцинировать" и начал точно исполнять ваши замыслы так же чётко, как опытный разработчик читает ТЗ, — нам есть что обсудить.
**Как это работает:**
1. **V2** дал нам "скелет" — граф притяжений и отталкиваний.
2. **Логопедия V3** дала нам "нейронные связи" — диагностическую цепочку: *Симптом → Диагностика → Заключение → Объяснение → Рекомендация*.
**Результат:** Чанк, который ИИ "читает" перед выполнением задачи, как логопед — карточку с упражнениями, или аналитик — утверждённое ТЗ.
Присоединяйтесь к обсуждению. Расскажу, как мы формализовали 5 уровней несовместимости (от этапной до временной) и почему "антипример" в ТЗ для ИИ важнее, чем позитивный пример.
Мы объединим два мощных подхода:
1. **Логопедическую модель** (диагностическая цепочка, связность, цельность, просодика)
2. **Техническое задание как промпт** (структура ТЗ из 1С-проектов, измеримость, границы, декомпозиция)
При этом ключевой инсайт из скиллов Claude — **чанк читается перед применением** — позволяет сделать базу знаний живой и обновляемой.
Я создам **гибридный фрагмент базы знаний**, который:
- Использует логопедическую структуру как основу
- Включает практики CLEAR v2 как инструмент сбора требований
- Опирается на структуру ТЗ как на формат финального промпта
- Учитывает архитектуру скиллов Claude как прототип реализации
---
## Вариант 1: JSON для chunks.json
```json
{
"id": 20,
"title": "Методология CLEAR-ТЗ: Формирование промпта как технического задания",
"phase": "analysis",
"role": "analyst",
"terms": ["ТЗ", "CLEAR", "границы", "AS-IS", "TO-BE", "декомпозиция", "измеримость"],
"full_text": "--- ГНОЗИС (узнавание) ---\n* **description:** Используй этот чанк, когда нужно сформулировать задачу для ИИ, особенно если задача сложная, требует нескольких итераций или предыдущие запросы давали размытые ответы. Чанк превращает промпт в техническое задание, понятное и человеку, и ИИ.\n* **keywords:** [\"промпт\", \"техническое задание\", \"ТЗ\", \"CLEAR\", \"требования\", \"границы\", \"AS-IS\", \"TO-BE\"]\n* **symptoms:** [\"ИИ даёт общие ответы, не применимые к конкретной задаче\", \"После ответа ИИ возникают уточняющие вопросы, которые можно было задать заранее\", \"Сгенерированный код не учитывает границы проекта\", \"Требования расползаются, ИИ добавляет лишнюю функциональность\", \"Результат нельзя проверить — нет критериев успеха\"]\n\n--- ПРАКСИС (действие) ---\n**Алгоритм работы с мастером CLEAR-ТЗ:**\n\n1. **Определи цель как измеримый результат** — не \"автоматизировать учёт\", а \"сократить время выгрузки с 2 часов до 10 минут в день\".\n\n2. **Ответь на 8 вопросов мастера** в структуре классического ТЗ:\n - Титульный лист и цель (измеримая)\n - Глоссарий (единый язык)\n - AS-IS и TO-BE (текущая и целевая ситуация с цифрами)\n - Границы (что НЕ делаем — важнее, чем что делаем)\n - Функциональные требования (атомарные, в формате \"Система должна [действие] для [роль]\")\n - Описание реализации (объекты 1С, форматы, протоколы)\n - Сценарии тестирования (шаг → реакция → связь с требованием)\n - Моделирование (схемы, диаграммы, макеты)\n\n3. **Проверь измеримость** — если в ответе есть слова \"удобно\", \"быстро\", \"качественно\" без цифр → переформулируй.\n\n4. **Проверь атомарность** — если требование содержит \"и\" → раздели на два.\n\n5. **Проверь границы** — если раздел \"Границы\" пуст → добавь хотя бы одно ограничение.\n\n6. **Сформируй промпт как ТЗ** по структуре ниже.\n\n7. **Добавь автоматические ссылки на чанки** — мастер сам определит, какие чанки нужны (клиент-сервер, расширения, условное оформление и т.д.).\n\n8. **Попроси уточнить перед выполнением** — добавь в промпт фразу: \"Перед выполнением: если что-то неясно — задай 2-3 уточняющих вопроса\".\n\n**Правильный пример (сбор требований):**\n\n*Вопрос: Титульный лист и цель*\n> Проект: Интеграция 1С:УНФ с Ozon. Версия: 1.0. Цель: ежедневная автоматическая выгрузка остатков на маркетплейс, сокращение ручных операций с 2 часов до 10 минут в день.\n\n*Вопрос: AS-IS и TO-BE*\n> AS-IS: остатки обновляются вручную 2 раза в день, ошибки выгрузки — 3-4 в неделю, потери из-за неактуальных остатков — 5-10% от оборота.\n> TO-BE: выгрузка автоматическая 2 раза в день, ошибки — не более 1 в месяц, снижение потерь до 1%.\n\n*Вопрос: Границы*\n> НЕ делаем: выгрузку по товарам без штрихкода, обработку возвратов, поддержку других маркетплейсов, изменение типовой логики проведения.\n\n**Антипример (размытый сбор требований):**\n\n*Вопрос: Титульный лист и цель*\n> Автоматизация торговли\n\n*Вопрос: AS-IS и TO-BE*\n> Сейчас всё плохо, надо автоматизировать\n\n*Вопрос: Границы*\n> Никаких жёстких ограничений нет\n\n--- ПРОСОДИКА (иерархия правил) ---\n* **критическое_правило (вес 0.6):** ВСЕГДА указывай измеримые цели и границы (что НЕ делаем). Это важнее, чем описание того, что делаем. Без измеримости нельзя проверить результат. Без границ требования расползаются.\n* **второстепенные_правила (вес 0.3):**\n * Декомпозируй требования до атомарного уровня — каждое требование должно быть проверяемым.\n * Используй единую терминологию из глоссария во всех разделах.\n * Привязывай сценарии тестирования к функциональным требованиям.\n* **исключения (вес 0.1):**\n * Если задача тривиальна (например, \"переименовать реквизит в форме\"), можно использовать упрощённую структуру.\n * Если проект уже имеет утверждённое ТЗ, можно ссылаться на него, а не пересобирать.\n\n--- ДИАГНОСТИЧЕСКАЯ ЦЕПОЧКА ---\n* **симптом:** ИИ генерирует код, который технически верен, но не решает бизнес-задачу, или добавляет лишнюю функциональность.\n* **диагностика:** Промпт содержал размытые цели и не содержал границ. ИИ дополнил пробелы наиболее вероятными, но не всегда релевантными вариантами.\n* **заключение:** Нарушен паттерн \"измеримость и границы\". ИИ не может отличить обязательные требования от пожеланий.\n* **объяснение:** ИИ — это модель дополнения. Если не указать чёткие границы, модель будет добавлять всё, что считает \"обычным\" для такой задачи. Если цель не измерима, модель не может оптимизировать решение под нужный критерий.\n* **рекомендация:** Используй мастер CLEAR-ТЗ. Он проведёт через все 8 разделов классического ТЗ, обеспечивая измеримость, атомарность и наличие границ. Это превратит промпт из пожелания в техническое задание, которое ИИ сможет выполнить точно и проверяемо.\n\n--- СВЯЗАННЫЕ ЧАНКИ (автоматически подключаются мастером) ---\n* ЧАНК 5: Клиент-серверное взаимодействие — если в требованиях есть упоминание серверных вызовов\n* ЧАНК 12: Расширения — если проект реализуется в расширении\n* ЧАНК 16: Условное оформление — если есть требования к визуализации\n* ЧАНК 19: Методология CLEAR v2 — базовая методология\n* ЧАНК 20: CLEAR-ТЗ — текущий чанк\n\n--- ФОРМАТ ФИНАЛЬНОГО ПРОМПТА (структура ТЗ) ---\n\n```\n=== ТЕХНИЧЕСКОЕ ЗАДАНИЕ ===\n\n1. Титульный лист\n Название: [название проекта]\n Версия: [версия]\n Цель: [измеримая цель]\n\n2. Глоссарий\n [список терминов и определений]\n\n3. Общие цели\n AS-IS: [текущая ситуация с цифрами]\n TO-BE: [желаемый результат с цифрами]\n\n4. Границы и ограничения\n Система НЕ делает:\n - [список запретов]\n\n5. Функциональные требования\n - [список в формате \"Система должна [действие] для [роль]\"]\n\n6. Описание реализации\n Объекты 1С: [список]\n Форматы: [описание]\n Протоколы: [описание]\n Расписание: [описание]\n\n7. Сценарии тестирования\n | Шаг пользователя | Ожидаемая реакция системы | Связь с требованием |\n |------------------|--------------------------|---------------------|\n\n8. Моделирование\n [ссылки на схемы, диаграммы, макеты]\n\n--- ДОПОЛНИТЕЛЬНЫЕ УКАЗАНИЯ ---\nПеред выполнением: если что-то неясно — задай 2-3 уточняющих вопроса.\nПосле выполнения: сначала покажи рассуждение, потом дай код.\nКод должен соответствовать требованиям безопасности (ЧАНК 1), клиент-серверному взаимодействию (ЧАНК 5) и работе с расширениями (ЧАНК 12).\n```"
}
```
---
## Вариант 2: Человекочитаемая версия
# Методология CLEAR-ТЗ: Формирование промпта как технического задания (Чанк 20)
### --- ГНОЗИС (узнавание) ---
**Используй этот чанк, когда:**
Нужно сформулировать задачу для ИИ, особенно если задача сложная, требует нескольких итераций или предыдущие запросы давали размытые ответы. Чанк превращает промпт в техническое задание, понятное и человеку, и ИИ.
**Ключевые симптомы, что ты делаешь что-то не так:**
- ИИ даёт общие ответы, не применимые к конкретной задаче
- После ответа ИИ возникают уточняющие вопросы, которые можно было задать заранее
- Сгенерированный код не учитывает границы проекта
- Требования расползаются, ИИ добавляет лишнюю функциональность
- Результат нельзя проверить — нет критериев успеха
### --- ПРАКСИС (действие) ---
**Алгоритм работы с мастером CLEAR-ТЗ:**
1. **Определи цель как измеримый результат** — не "автоматизировать учёт", а "сократить время выгрузки с 2 часов до 10 минут в день".
2. **Ответь на 8 вопросов мастера** в структуре классического ТЗ:
- Титульный лист и цель (измеримая)
- Глоссарий (единый язык)
- AS-IS и TO-BE (текущая и целевая ситуация с цифрами)
- Границы (что НЕ делаем — важнее, чем что делаем)
- Функциональные требования (атомарные, в формате "Система должна [действие] для [роль]")
- Описание реализации (объекты 1С, форматы, протоколы)
- Сценарии тестирования (шаг → реакция → связь с требованием)
- Моделирование (схемы, диаграммы, макеты)
3. **Проверь измеримость** — если в ответе есть слова "удобно", "быстро", "качественно" без цифр → переформулируй.
4. **Проверь атомарность** — если требование содержит "и" → раздели на два.
5. **Проверь границы** — если раздел "Границы" пуст → добавь хотя бы одно ограничение.
6. **Сформируй промпт как ТЗ** по структуре ниже.
7. **Добавь автоматические ссылки на чанки** — мастер сам определит, какие чанки нужны.
8. **Попроси уточнить перед выполнением** — добавь в промпт фразу: "Перед выполнением: если что-то неясно — задай 2-3 уточняющих вопроса".
**Правильный пример (сбор требований):**
*Вопрос: Титульный лист и цель*
> Проект: Интеграция 1С:УНФ с Ozon. Версия: 1.0. Цель: ежедневная автоматическая выгрузка остатков на маркетплейс, сокращение ручных операций с 2 часов до 10 минут в день.
*Вопрос: AS-IS и TO-BE*
> AS-IS: остатки обновляются вручную 2 раза в день, ошибки выгрузки — 3-4 в неделю, потери из-за неактуальных остатков — 5-10% от оборота.
> TO-BE: выгрузка автоматическая 2 раза в день, ошибки — не более 1 в месяц, снижение потерь до 1%.
*Вопрос: Границы*
> НЕ делаем: выгрузку по товарам без штрихкода, обработку возвратов, поддержку других маркетплейсов, изменение типовой логики проведения.
**Антипример (размытый сбор требований):**
*Вопрос: Титульный лист и цель*
> Автоматизация торговли
*Вопрос: AS-IS и TO-BE*
> Сейчас всё плохо, надо автоматизировать
*Вопрос: Границы*
> Никаких жёстких ограничений нет
### --- ПРОСОДИКА (иерархия правил) ---
* **Критическое правило (вес 0.6):** ВСЕГДА указывай измеримые цели и границы (что НЕ делаем). Это важнее, чем описание того, что делаем. Без измеримости нельзя проверить результат. Без границ требования расползаются.
* **Второстепенные правила (вес 0.3):**
* Декомпозируй требования до атомарного уровня — каждое требование должно быть проверяемым.
* Используй единую терминологию из глоссария во всех разделах.
* Привязывай сценарии тестирования к функциональным требованиям.
* **Исключения (вес 0.1):**
* Если задача тривиальна (например, "переименовать реквизит в форме"), можно использовать упрощённую структуру.
* Если проект уже имеет утверждённое ТЗ, можно ссылаться на него, а не пересобирать.
### --- ДИАГНОСТИЧЕСКАЯ ЦЕПОЧКА ---
* **Симптом:** ИИ генерирует код, который технически верен, но не решает бизнес-задачу, или добавляет лишнюю функциональность.
* **Диагностика:** Промпт содержал размытые цели и не содержал границ. ИИ дополнил пробелы наиболее вероятными, но не всегда релевантными вариантами.
* **Заключение:** Нарушен паттерн "измеримость и границы". ИИ не может отличить обязательные требования от пожеланий.
* **Объяснение:** ИИ — это модель дополнения. Если не указать чёткие границы, модель будет добавлять всё, что считает "обычным" для такой задачи. Если цель не измерима, модель не может оптимизировать решение под нужный критерий.
* **Рекомендация:** Используй мастер CLEAR-ТЗ. Он проведёт через все 8 разделов классического ТЗ, обеспечивая измеримость, атомарность и наличие границ. Это превратит промпт из пожелания в техническое задание, которое ИИ сможет выполнить точно и проверяемо.
### --- СВЯЗАННЫЕ ЧАНКИ (автоматически подключаются мастером) ---
* ЧАНК 5: Клиент-серверное взаимодействие — если в требованиях есть упоминание серверных вызовов
* ЧАНК 12: Расширения — если проект реализуется в расширении
* ЧАНК 16: Условное оформление — если есть требования к визуализации
* ЧАНК 19: Методология CLEAR v2 — базовая методология
* ЧАНК 20: CLEAR-ТЗ — текущий чанк
3. Общие цели
AS-IS: [текущая ситуация с цифрами]
TO-BE: [желаемый результат с цифрами]
4. Границы и ограничения
Система НЕ делает:
- [список запретов]
5. Функциональные требования
- [список в формате "Система должна [действие] для [роль]"]
6. Описание реализации
Объекты 1С: [список]
Форматы: [описание]
Протоколы: [описание]
Расписание: [описание]
7. Сценарии тестирования
| Шаг пользователя | Ожидаемая реакция системы | Связь с требованием |
|------------------|--------------------------|---------------------|
| [шаг] | [реакция] | №[требования] |
8. Моделирование
[ссылки на схемы, диаграммы, макеты]
--- ДОПОЛНИТЕЛЬНЫЕ УКАЗАНИЯ ---
Перед выполнением: если что-то неясно — задай 2-3 уточняющих вопроса.
После выполнения: сначала покажи рассуждение, потом дай код.
Код должен соответствовать требованиям безопасности (ЧАНК 1),
клиент-серверному взаимодействию (ЧАНК 5) и работе с расширениями (ЧАНК 12).
```
---
## Итог: Как объединены подходы
| Элемент | Логопедический подход | CLEAR-ТЗ | Синтез в чанке 20 |
|---------|----------------------|----------|-------------------|
| **Гнозис** | Симптомы, ключевые слова | Context, Audience | Описание, когда применять + симптомы ошибок |
| **Праксис** | Алгоритм + пример + антипример | Examples, Requirements | 8-шаговый алгоритм + правильный/неправильный пример сбора требований |
| **Просодика** | Иерархия правил (веса) | Limits, Constraints | Критическое правило (границы и измеримость) с весом 0.6 |
| **Диагностическая цепочка** | Симптом → диагностика → заключение → объяснение → рекомендация | AS-IS → TO-BE | Полная цепочка, объясняющая, почему размытые промпты не работают |
| **Связность** | Единая терминология | Глоссарий | Связанные чанки и единый формат ТЗ |
| **Архитектура** | Скиллы Claude (читаются перед применением) | Модуль clear_wizard.py | Чанк может обновляться независимо от модели, мастер подключает нужные чанки автоматически |
**Ключевые улучшения против классического CLEAR:**
1. **Role удалён** — по наблюдениям Клода, роль переоценена
2. **Length заменён структурой** — вместо "500 слов" — чёткая структура ТЗ
3. **Constraints выделены отдельно** — границы и ограничения стали отдельным разделом
4. **AS-IS и TO-BE добавлены** — измеримость целей стала обязательной
5. **Сценарии тестирования добавлены** — проверяемость требований стала явной
6. **Связь с чанками автоматическая** — мастер сам определяет, какие чанки нужны
**Главный принцип, объединяющий всё:** *Промпт — это техническое задание. Чем точнее ТЗ, тем меньше итераций.*