Когда в продукте появляется раздел уведомлений, его легко собрать как одну общую ленту. На практике это выглядит логично только до тех пор, пока не начинаешь разбирать, какие именно события туда попадают. В проекте StarSmile у нас в уведомлениях оказалось сразу несколько разных типов уведомлений. Есть системные уведомления. Например, сообщение о технических работах. Есть промо и маркетинговые уведомления. Есть сообщения от лаборатории. Они привязаны к заказу, но по смыслу это уже не просто уведомление, а вход в конкретный чат с конкретным человеком. Есть уведомления по статусам заказа. У каждого типа уведомлений своё назначение в системе, поэтому и жизненный цикл у них разный...
ТЗ, написанное ИИ видно сразу: по структуре, формулировкам, описанию функционала, требованиям. Его можно брать за основу, созваниваться с клиентом и проговаривать каждый пункт: что имелось в виду, что значит, для чего. Возможно, даже скорее всего, даже 100%, после этого ТЗ сократится, станет совершенно иным, часть требований будет описано совершенно иначе...
Но ни подробное ТЗ, ни сгенерированный экран не закрывают основную интерфейсную задачу, если в них не собрана пользовательская логика. Недавно в проекте Planum появилась задача разработать настройку расписаний запуска системных процессов. Внутри настройки лежал cron-логика: набор правил, по которым система автоматически запускает задачу в нужное время. Такая настройка должна оставаться гибкой и не превращаться в перегруженную форму. У этой задачи тоже было собранное с помощью AI техническое задание...
4 дня назад
Если нравится — подпишитесь
Так вы не пропустите новые публикации этого канала