Нейросеть для проверки технических заданий: приёмка CSV
Нейросеть для проверки технических заданий: как найти неоднозначность в ТЗ на CSV и составить измеримую приёмку. Контрольные данные, вопросы и протокол.
Денис
Продакт LibraChat
8 мин чтения
Сможет ли подрядчик сам проверить свою работу до встречи с заказчиком? Я начинаю чтение ТЗ с этого вопроса. Для кнопки выгрузки мне нужны четыре контрольные записи, понятный способ открытия файла и ожидаемый результат каждого действия. Нейросеть для проверки технических заданий помогает найти места, где двое читателей пока представляют разную приёмку. Дальше эти места нужно превратить в решения, по которым можно работать.
Нейросеть для проверки технических заданий: что ей передать
Возьмём ТЗ на небольшой каталог запчастей. В нём написано: «Добавить кнопку “Скачать CSV”. Выгрузка содержит код, наименование и примечание. Нужно выгружать список из текущей категории, чтобы файл корректно открывался в Excel. Все данные должны сохраниться». Звучит достаточно предметно. Однако по этой записи ещё нельзя решить, какие именно строки попадут в файл и как его будет открывать получатель.
Я сначала выписываю, ради чего нужна функция: сотрудник передаёт каталог в другую программу и должен узнавать те же товары по кодам. Поэтому корректность кода важнее декоративного вида таблицы. Если файл используют только для просмотра, требования могут быть другими. Цель выгрузки стоит записать рядом с её описанием, иначе замечания к ТЗ начнут незаметно расширять задачу.
Для проверки документа я готовлю копию с требованиями и приложениями, на которые они ссылаются. В LibraChat можно прикрепить Word или PDF и попросить разбор содержания. Объём и доступные режимы работы с файлами сверяю с условиями тарифов, когда известен размер документа. Для самого первого обсуждения хватает текста задачи и описания пользователя, который получит выгрузку.
Переписывать документ рано. Мне нужен перечень проверяемых требований и открытых решений. Эти два списка различаются. В первом уже можно составлять проверки, во втором предстоит договориться о поведении функции. Пока ответы не получены, оформленная таблица замечаний сама по себе не делает ТЗ законченным.
Собрать данные, на которых видно расхождение
Я сделал 4 карточки. Нам не нужны сотни настоящих позиций: достаточно набора, где каждый спорный случай можно увидеть отдельно. Код содержит ведущие нули. В одном названии стоит запятая, в другом — кавычка. Ещё есть перенос в примечании и две пустоты. Это разные свойства данных. Обычного товара здесь недостаточно.
Код · Наименование · Примечание · Что проверяем
0007 — Рычаг, длинный — пусто — Нули в коде и запятую внутри названия
BK-12 — Ключ 12" — Проверить комплект — Кавычку как часть значения
KM-8 — Крепление — Верхняя полка ↵ Нижняя полка — Перенос внутри одного примечания
LM-9 — Зажим — пусто — Сохранение пустого поля
Знак ↵ здесь обозначает настоящий перенос в значении. Новый товар не появился. Я собрал текст CSV из этих карточек и прочитал его обратно локальным разборщиком: получилось четыре записи с тремя полями, а физических текстовых строк — шесть с учётом заголовка. Поэтому требование «в файле должно быть пять строк» было бы плохой проверкой количества карточек.
CSV должен сохранить границы полей. Значение с запятой или переносом заключают в двойные кавычки. Внутреннюю двойную кавычку дублируют. В нашем названии «Ключ 12"» она одна, а внутри CSV-поля записывается 2 раза. Читателю файла должны вернуться исходные значения. Для заказчика важен именно этот результат: название не разъехалось по соседним колонкам, а примечание не превратилось в дополнительную карточку.
Отдельно проверяется код. Сам текст CSV не сообщает программе, что колонка должна считаться текстовой. Excel может автоматически преобразовать числовой код и убрать начальные нули. Поэтому в ТЗ нужно определить среду и способ импорта. В протоколе указываю, что колонку импортируют с типом «Текст», а приёмка проверяет значение `0007` после открытия выбранным способом.
Это два разных основания проверки: что записал экспорт и как результат прочитала программа получателя. Если нужен сценарий простого открытия без настройки импорта, его надо отдельно согласовать. Фраза «корректно открывается в Excel» не заменяет описание такого сценария. Версия программы и порядок действий относятся к условиям приёмки, а не к вкусу проверяющего.
Нейросеть для проверки технических заданий: запрос к разбору
В LibraChat я передал исходную запись о кнопке и условия контрольного набора. Попросил отделить требования от решений, которые ещё не выбраны, и составить протокол с входными условиями, действием и наблюдаемым результатом. Чат не должен назначать фильтры или порядок колонок от лица заказчика только потому, что исходник об этом молчит.
Вот основная часть запроса после фрагмента ТЗ:
Отдели уже заданные требования от решений, которые ещё нужно согласовать с заказчиком. Не считай молчание ТЗ разрешением самому выбрать фильтры, сортировку, состав строк или формат файла. Предложи компактный протокол приёмки: входные условия, действие, ожидаемый наблюдаемый результат. Контрольный набор: четыре записи каталога с тремя полями; одна запятая внутри названия, одна двойная кавычка, один перенос внутри примечания, два пустых примечания. Не создавай файл и не заявляй, что будущая программа уже протестирована.
В ответе LibraChat выделил важную деталь исходной формулировки:
«Содержит» не значит «только эти поля». Порядок колонок, заголовок, его текст и лишние колонки не заданы.
Я проверил это замечание по исходнику. Там действительно перечислено, что в выгрузке есть, но не установлено, что других колонок быть не должно. Если заказчик ждёт ровно три поля в определённом порядке, лучше написать это прямо. Иначе приёмка начнёт требовать условие, которого исполнителю не передали.
Попробуй разобрать своё ТЗ в LibraChat с таким разделением. Сначала проверь связь замечания с конкретным пунктом документа. Затем реши, какое поведение нужно продукту. Формулировку «только три поля: код, наименование, примечание, в этом порядке» я уже добавляю как принятое решение, а не как цитату из прежнего ТЗ.
Сделать протокол, который можно выполнить
После обсуждения у нашей выгрузки появилось правило состава: все карточки выбранной категории, независимо от текущей страницы списка. Поиск на экране в этом сценарии не меняет выгрузку. Также согласованы ровно три колонки, их названия и порядок. Это условия конкретной функции, а не универсальное поведение любой кнопки CSV. Другой продукт может выбрать иначе.
Теперь можно написать проверку с определённым исходом. Для стенда в выбранной категории лежат четыре карточки из таблицы, а в соседней — ещё одна. На экране видно по две позиции. Приёмка ожидает четыре записи в файле, даже если открыта первая страница. Соседняя категория исключена. Так проверяется согласованный состав, а не только наличие скачанного файла.
Подготовить категории и контрольные карточки, зафиксировать их значения.
Открыть выбранную категорию и нажать «Скачать CSV».
Проверить число записей, состав и порядок колонок, отсутствие соседней категории.
Импортировать результат в согласованной среде выбранным способом.
Сопоставить все три поля каждой карточки с контрольным набором.
Рядом с каждым пунктом я оставляю место для фактического результата и подтверждения. Часть проверки может пока не выполняться: например, заказчик ещё не назвал среду получателя. Тогда в протоколе остаётся открытый вопрос. Называть такой пункт пройденным или заменять его удобным способом открытия нельзя. Сначала нужно согласовать условие, затем выполнить действие.
Отдельно назвать результат пустой выгрузки
Четыре карточки проверяют основной маршрут, но у пустой категории другой результат. Скачивается файл с одними заголовками, показывается сообщение или кнопка недоступна? Каждый вариант может быть осмысленным. Требуется одно утверждённое решение. Я добавляю такую проверку отдельно, чтобы пустая категория не оставалась случайностью демонстрации.
То же относится к недоступному действию для пользователя без нужных прав. Не стоит выводить право на выгрузку из того, что человек видит каталог. Список ролей и разрешённые операции задаёт владелец продукта. Нейросеть может заметить незаданный вопрос, но согласовать полномочия за команду не должна. Для маленького ТЗ достаточно назвать этот пробел; раздувать его до полной новой системы доступа незачем.
Если документ ещё только собирается, сначала удобно описать само техническое задание, а затем проверять его на таких сценариях. Добавленный пункт должен оставаться связанным с назначением функции. Иначе вместо проверки получишь проект другого сервиса: больше возможностей, больше работы и прежняя неопределённость в самом нужном месте.
Передать приёмку на независимое чтение
Я заканчиваю проверку двумя вопросами к сторонам. Заказчик: «По какому пункту ты решишь, что получил нужный каталог?» Исполнитель: «Что ты покажешь, чтобы подтвердить этот пункт?» Оба должны сослаться на один и тот же наблюдаемый результат. Если один ждёт четыре карточки, а другой две видимые строки экрана, возвращаемся к составу выгрузки до разработки.
Хороший итог разбора — перечень согласованных требований, отдельный остаток вопросов и исполнимый протокол. Дай заказчику и исполнителю прочитать его независимо. Совпали ожидаемые результаты? Можно обсуждать реализацию. Не совпали — у вас уже есть конкретный пункт для разговора, а не спор о том, насколько подробно написано ТЗ.
