Лучшая нейросеть для системного аналитика: проверка на трёх задачах
Лучшая нейросеть для системного аналитика — та, что выдерживает твои задачи. Проверяю LibraChat на историях, противоречиях в требованиях и модели данных.
Денис
Продакт LibraChat
7 мин чтения
Лучшая нейросеть для системного аналитика — та, чей результат на твоих задачах можно проверить и довести до дела. Рейтинги тут мало помогают: у аналитика рутина своя. Я взял три типовые задачи — разбить требование на истории, найти противоречия, собрать модель данных — и прогнал их в LibraChat. Две прошли хорошо. Третья пришла аккуратным файлом, в котором аналитик сразу увидит дыры.
Почему именно эти три? Они покрывают почти всю неделю аналитика: перевести слова заказчика в язык команды, найти, где требования спорят друг с другом, и разложить предметную область на сущности. Если нейросеть помогает хотя бы в двух из трёх, она уже окупает время на запрос.
Общий принцип такой. Нейросеть ускоряет черновик и ловит то, что глаз пропускает к вечеру. Но решение о том, что заказчик имел в виду, остаётся за тобой: она не знает ни бизнеса, ни договорённостей на последней встрече.
Ситуация первая: требование в пользовательские истории
Типичная задача на понедельник: заказчик прислал одну строку, а команде нужны истории с критериями приёмки. Я отправил так:
Я системный аналитик. Требование заказчика: «Клиент должен видеть статус заказа и получать уведомление, когда заказ передан в доставку». Разбей его на пользовательские истории с критериями приёмки в формате «Дано — Когда — Тогда» и выпиши вопросы, которые нужно задать заказчику.
Замени требование в кавычках на своё, остальное подойдёт как есть. Отдельного режима для аналитиков искать не нужно: запрос уходит в LibraChat как есть.
Ответ начался с правильного хода:
Требование распадается минимум на две независимые пользовательские истории: просмотр статуса и уведомление о передаче в доставку.
Дальше две истории в формате «как клиент я хочу… чтобы…» и по четыре-пять критериев на каждую. Что я бы засчитал: в критериях есть не только счастливый путь. Чужой заказ не показывается. Повторное уведомление по тому же событию не отправляется. Сбой канала фиксируется. Вот строка из одного критерия:
Тогда: повторное уведомление по этому же событию не отправляется.
Такие негативные сценарии обычно и забывают в первой версии, а потом ловят на тестировании.
Доработать руками всё же придётся. В одном критерии сказано, что повтор отправки идёт «по согласованным правилам». Каким именно, в ответе не сказано, и это правильно: правила знает заказчик. Это место аналитик заполняет сам, после разговора с заказчиком. Хорошо, что оно видно, а не спрятано за гладкой формулировкой.
Самое ценное — вопросы заказчику. Их пришло два десятка, разбитых по темам. Например:
Клиент — только авторизованный пользователь или статус доступен и гостю, например по номеру заказа и телефону?
И честная оговорка в конце: статусы, каналы и правило «одно уведомление на переход» — рабочие допущения, пока заказчик их не подтвердил. Я бы не отправлял вопросы списком из двадцати пунктов. Выбрал бы пять, без которых истории не начать, остальные — на встречу.
Ситуация вторая: противоречия в требованиях
Вторая задача — ревью. Я дал пять требований к интернет-магазину, нарочно со скрытыми конфликтами:
Найди противоречия и пробелы в требованиях к интернет-магазину: 1) заказ можно отменить до передачи в доставку; 2) после оплаты заказ сразу уходит на склад и в доставку; 3) клиент может изменить адрес в любой момент; 4) уведомления отправляются по SMS; 5) клиент может отключить все уведомления. Для каждой проблемы предложи вопрос заказчику.
Первая фраза ответа попала точно:
Между этими пятью пунктами заказ почти не успевает существовать как управляемый объект: оплата сразу уводит его в доставку, а клиенту при этом обещают отмену, смену адреса и тишину в уведомлениях.
Нашлись все три заложенных конфликта: отмена против мгновенной доставки, адрес «в любой момент» против ушедшего курьера, SMS как один способ связи против права всё отключить. Плюс два пробела, которых я не закладывал специально: нет цепочки статусов и не описаны деньги при отмене.
Самый полезный вопрос из ответа я бы скопировал в письмо без правок:
Вопрос заказчику: напишите цепочку статусов от создания до вручения и для каждого укажите: можно ли отменить, можно ли сменить адрес, возвращаются ли деньги и за чей счёт.
На практике я бы гонял так собственные требования перед каждой встречей с заказчиком. Пять минут чтения ответа, и в повестке уже есть список острых мест, а не надежда, что их заметят по ходу.
Одну вещь я бы проверил отдельно. В разборе про уведомления ответ упоминает, что часть сообщений обязательна по закону. Для ревью это полезный флажок, но ссылаться на закон в документе я бы стал только после юриста.
Ситуация третья: модель данных файлом
Третья задача — с выдачей файла. Я попросил:
Составь модель данных для учёта заказов интернет-магазина: сущности, атрибуты, типы данных и связи между сущностями. Сделай таблицу в Excel.
Пришёл файл Excel с четырьмя сущностями: клиент, товар, заказ и позиция заказа. У каждой — атрибуты, типы данных, описание и связи вроде «многие к одному». Для старта обсуждения или учебного примера — нормально. Таблицу можно сразу открыть и показать команде.
А дальше включается аналитик. Глядя на файл после второй ситуации, я вижу как минимум три дыры:
адрес хранится у клиента, а не у заказа, хотя требования просят менять адрес доставки по конкретному заказу;
статус — просто строка внутри заказа, без истории изменений, а без неё не ответить, когда заказ ушёл в доставку;
уведомлений и способов связи в модели нет вовсе, хотя половина требований про них.
Файл пришёл потому, что в запросе прямо названо: «таблицу в Excel». Без этих слов LibraChat показал бы таблицу прямо в ответе, а не файлом. Для обсуждения в чате это даже удобнее, для передачи команде нужен файл.
Так что третий ответ — хороший черновик, а не готовая модель. Это нормально: в запросе не было ни слова о требованиях из второй задачи, каждая шла в новом чате. Если вести все три задачи в одном чате, LibraChat учитывает то, что обсуждалось выше, и модель можно попросить доработать под найденные противоречия следующим сообщением. Сам файл там же и правится, формат сохраняется.
Что проверить, прежде чем отдавать команде
После трёх задач у меня сложился короткий список проверки:
допущения — всё, что нейросеть приняла за данность, отмечено как вопрос, а не как требование;
негативные сценарии — в критериях есть ошибки, повторы и чужие данные, а не только счастливый путь;
связность — модель данных и истории описывают один и тот же процесс;
конфиденциальность — в запросе нет имён клиентов, реальных цен и внутренних систем заказчика: для разбора они не нужны.
Сам запрос у меня во всех трёх задачах строился одинаково. Кто я, что за артефакт нужен, в каком формате, и обязательно «выпиши вопросы». Последнее — главное. Без него нейросеть закрывает пробелы догадками, с ним показывает их тебе.
О границах скажу прямо. Нейросеть не знает домена и того, о чём договорились устно. Она быстро даёт каркас и ловит логические конфликты. Решать, какой из конфликтов важен, и согласовывать это с людьми — работа аналитика.
Возьми последнее требование, над которым ты сидел дольше всего, и отправь его первым запросом. Оцени не красоту ответа, а одно: сколько вопросов заказчику из списка ты бы не задал сам. Если хотя бы пара нашлась, в твоей рутине нейросеть уже на своём месте.
лучшая нейросеть для системного аналитикабыт и личноетребованияаналитика
