Post #858

Я в последнее время много наблюдаю за аналитиками, работающими с ИИ. И, кажется, я понял кое-что, что может нам помочь в работе даже безотносительно использования чатов. Дело в том, что мы не понимаем, чем мы на самом деле занимаемся. Сейчас объясню. Вот что я увидел, когда человек работает с ИИ: 1) Давать писать документ целиком ИИ — очень плохо. Оказывается, когда мы пишем самостоятельно текст — мы его обдумываем и запоминаем. Поэтому так хорошо работают конспекты лекций. Ты запоминаешь и создаешь в голове карту. В одной системе у меня было 900 таблиц и полторы тысячи хранимых процедур, но так как я их каждую сам вручную создал — я их все помнил "в лицо", и знал — где что поправить, если что. Когда я пишу ТЗ или проект системы — я помню все роли пользователей, их основные сценарии, объекты данных, требования. Если всё это напишет ИИ — максимум, что я смогу сделать — прочитать про это. Но прочитать — совсем не равно "запомнить" или "построить мысленную карту". Для этого нужно что-то с этим документом сделать, как-то поработать с ним. 2) Читать готовый документ и понимать его вообще тяжело. Поэтому программисты и не читают ваши постановки. Это вам весь документ знаком и понятен, ну вы же его писали, и он у вас загружен в голову. А точнее — не загружен, а постепенно там вырос. Хороший аналитик знает, что если внести изменение в одном месте — нужно будет поменять и в другом. А вот программисту нужно как-то это в голову уместить, а оно целым куском не лезет. Теперь мы можем на своей шкуре это испытать: ИИ написал, а нам в голову нужно запихнуть. И не лезет. Поэтому, кстати, желательно бить задачу на отдельные промпты и небольшие артефакты, даже если чат может сразу весь документ сгенерить. Иначе не сформируется понимание. 3) Каждый артефакт — это одна из моделей будущей системы. То есть, некий срез наших представлений о системе — в статике или в динамике, с точки зрения бизнес-потребностей, функций приложения или данных. Да, это опять похоже на MDD — Model Driven Development — штуку, которая в свое время так и не взлетела. Мне кажется, не взлетела она по причине того, что пыталась опираться на UML, то есть на графические модели, причем не вполне формальные. А системы картинками плохо описываются. Нужны тексты. И тексты раньше не могли быть моделями. Ну и генерировать из моделей код раньше тоже получалось плохо, потому что, знаете — есть некоторый люфт между набором моделей и кодом. Теперь с текстами получается лучше, и опять появляются идеи разработки, управляемой спецификациями. Каждый новый артефакт заставляет взглянуть на систему по-новому: задать новые вопросы и принять новые решения. Именно так, кстати, можно понять — нужен ли вам тот или иной артефакт, та или иная форма записи требований — дает она повод задать новые вопросы, которые раньше не звучали? Требования не говорят о роли пользователя и его потребностях, а user story позволяет задать вопросы об этом. В user story нет контекста, а в job story можно спросить — в какой момент эта потребность возникает? Когда система находится в каком состоянии? Фокус смещается, новые вопросы появляются. А вот если мы составили use case, там уже есть и роль, и потребность, и контекст. Каждый новый артефакт должен позволять сделать хотя бы небольшой следующий шаг. Поэтому, кстати, нет смысла в юскейсах, повторяющих операции создать, изменить, удалить — тут нет повода задать новые вопросы. Задать вопросы, и получить ответы. А теперь — самое главное 👇👇👇