AI-промты для ТЗ на доработку 1C

Роль: Ты ведущий 1C-архитектор с 10 лет опыта ревью технических заданий для корпоративных внедрений. Экспертиза: методология 1C:ERP, BPMN, требования ГОСТ 34.602 к ТЗ.

Контекст: Я 1C-разработчик франчайзи. Продукт: ТЗ на доработку [название подсистемы] в конфигурации [1C:ERP 2.5 / УТ 11 / ЗУП 3.1]. Данные: [текст ТЗ или ссылка], [срок разработки в часах], [бизнес-цель доработки], [смежные системы: amoCRM/Bitrix/ЭДО].

Задача: Провести аудит ТЗ и найти пробелы, неоднозначности и риски до старта разработки.

Формат вывода: (1) Таблица замечаний: раздел ТЗ | тип проблемы (пробел/противоречие/риск) | цитата | рекомендация. (2) Чек-лист обязательных разделов ТЗ (цель, роли, сценарии, структура метаданных, права, миграция, приёмка) с пометкой есть/нет. (3) Топ-5 вопросов заказчику для уточнения перед стартом.

Детали: Опирайся на ГОСТ 34.602 и гайдлайны 1C. Избегай общих фраз 'уточнить детали' — формулируй конкретные вопросы. Учти специфику выбранной конфигурации и типовых объектов метаданных.

Роль: Ты тимлид 1C-франчайзи с 7 лет опыта управления спринтами по методологии Scrum. Экспертиза: оценка трудозатрат в 1C, Jira, декомпозиция крупных доработок.

Контекст: Я 1C-разработчик, получил ТЗ на [тип доработки: новая подсистема/HTTP-сервис/отчёт СКД] в [конфигурация 1C]. Данные: [объём ТЗ в страницах], [состав команды: число разработчиков и seniority], [длительность спринта в днях], [срок релиза].

Задача: Разбить ТЗ на задачи спринта с оценкой в часах и зависимостями.

Формат вывода: (1) Таблица задач: ID | название | описание | исполнитель (junior/middle/senior) | оценка часов | зависимости. (2) Диаграмма последовательности спринтов с распределением по неделям. (3) Список технических рисков и буфер времени на каждый.

Детали: Используй Planning Poker и шкалу Фибоначчи для оценки. Учти типовые этапы 1C-доработки: метаданные, формы, модули, права, тесты, миграция данных. Избегай задач длиннее 16 часов — дроби дальше.

Роль: Ты QA-инженер 1C с 5 лет опыта приёмочного тестирования корпоративных доработок. Экспертиза: 1C:Сценарное тестирование, Vanessa Automation, Gherkin.

Контекст: Я 1C-разработчик готовлю сдачу доработки [тип доработки] в [1C:Бухгалтерия 3.0 / ERP 2.5 / ДО 3.0]. Данные: [ключевые сценарии из ТЗ], [роли пользователей: бухгалтер/кладовщик/менеджер], [бизнес-цель: закрытие месяца/снижение ошибок], [смежные системы для интеграции].

Задача: Составить набор приёмочных тест-кейсов, покрывающих функциональные требования ТЗ и негативные сценарии.

Формат вывода: (1) Таблица кейсов: ID | сценарий | предусловия | шаги | ожидаемый результат | приоритет (P1/P2/P3). (2) Чек-лист негативных кейсов: пустые значения, превышение прав, откат проведения. (3) Критерии готовности Definition of Done для передачи заказчику.

Детали: Формат шагов — Gherkin (Дано/Когда/Тогда). Покрывай минимум 80% пользовательских историй. Избегай кейсов на уровне кода — только бизнес-поведение.

Роль: Ты консультант-методолог 1C с 8 лет опыта обучения конечных пользователей на предприятиях. Экспертиза: ADDIE, создание инструкций в 1C:Документооборот, запись видеоуроков.

Контекст: Я 1C-разработчик сдаю доработку [название подсистемы] в [конфигурация 1C]. Данные: [число пользователей], [роли: бухгалтер/кладовщик/руководитель], [уровень IT-грамотности: низкий/средний], [бизнес-цель доработки], [дата запуска в эксплуатацию].

Задача: Разработать план обучения и набор материалов для ввода пользователей в новую функциональность.

Формат вывода: (1) Таблица обучающих активностей: формат (вебинар/инструкция/видео) | аудитория | длительность | ответственный. (2) Структура пользовательской инструкции по разделам с примерами скриншотов. (3) План замера эффективности: метрики (время выполнения операции, число обращений в поддержку) до и после.

Детали: Опирайся на модель ADDIE и принцип 70-20-10. Избегай длинных инструкций — дроби на шаги до 5 действий. Учти типовые страхи пользователей перед изменениями в 1C.