Прибыль:
- Возможность превращать расплывчатые бизнес-запросы в четкие, тестируемые требования к программному обеспечению и пользовательские истории с поддержкой искусственного интеллекта.
- Способность структурированно сравнивать плюсы и минусы проектирования системы, модели данных и архитектурных решений с помощью ИИ.
- Способность критически проверять предлагаемую конструкцию ИИ на соответствие требованиям, масштабируемости и ограничениям.
Большинство программных проектов терпят неудачу не из-за плохого кода, а из-за неправильно понятых требований. Запрос в одно предложение, например «Разрешить пользователям загружать отчеты», оставляет после себя десятки вопросов без ответа: в каком формате? Кто главный? Сколько записей? Что, если это медленно? Анализ требований (преобразование бизнес-запроса в четкие, проверяемые технические потребности) и проектирование программного обеспечения (построение структуры на бумаге для удовлетворения этих потребностей) — это этапы, на которых предотвращаются самые дорогостоящие ошибки еще до написания кода. В этом разделе мы научимся использовать ИИ в качестве «мыслительного партнера» на этом этапе: партнера, который развеивает неопределенность, сортирует варианты, но оставляет окончательное решение за вами.
ИИ производит здесь две большие ценности. Во-первых, он задает вопросы, которые вы пропускаете; Это выявляет скрытые предположения и крайние случаи запроса. Во-вторых, он быстро сводит в таблицу плюсы и минусы проектного решения. Но в этом и есть опасность: ИИ будет давать общие рекомендации как «лучшую практику», не зная полностью вашего контекста (бюджет, команда, существующая система, юридические ограничения). Ваша задача – отфильтровать этот совет от вашей собственной правды.
Концепции: Пользовательская история: короткое предложение, выражающее потребность в форме «... поскольку я хочу иметь возможность... потому что...». Критерии приемки: проверяемые условия, которые должны быть выполнены, чтобы работа считалась «выполненной». Нефункциональные требования: требования, связанные с тем, «как оно будет вести себя», а не с тем, «что оно будет делать», например, скорость, безопасность, масштабируемость.
От расплывчатого запроса к проверяемому требованию
Хорошее требование измеримо и проверяемо. Не «пусть система будет быстрой», а «пусть результаты поиска возвращаются в течение 500 мс». Вот пошаговый способ использования ИИ для уменьшения неопределенности:
- Отправьте запрос как есть и сгенерируйте вопрос. Спрашивайте у ИИ не решение, а сначала «перечислите все неясное в этом запросе как вопрос».
- Вы даете ответы. Только вы знаете контекст; Отвечайте на вопросы ИИ, учитывая реальные бизнес-ограничения.
- Превратите это в пользовательские истории и критерии приемки. Преобразуйте выясненную потребность в проверяемые элементы.
- Добавьте крайние случаи и негативные сценарии. «Пустой результат», «неавторизованный пользователь», «слишком большой файл» и т. д.
Подсказка для извлечения неоднозначности: «Мы переведем следующий бизнес-запрос в требование к программному обеспечению. Пока не предлагайте решение. Сначала извлеките ВСЕ двусмысленности и скрытые предположения, на которые нет ответа в этом запросе, в виде списка вопросов. Сгруппируйте вопросы под следующими заголовками: объем, пользователь/полномочие, объем данных, производительность, условия возникновения ошибок, безопасность. Запрос: «Разрешить пользователям загружать историю заказов в виде отчета».
Пользовательская история + подсказка о критериях приемлемости: «Разделите следующую уточненную потребность на пользовательские истории, которые соответствуют принципам INVEST. Напишите 3-5 проверяемых критериев приемлемости для каждой истории (в формате «Дано-когда-то»). Добавьте как минимум 2 негативных сценария (несанкционированный доступ, пустые данные). Необходимо: [напишите здесь уточненную потребность]».
Сравнение проектных решений с ИИ
Дизайн — это постоянный компромисс: скорость или гибкость, простота или масштабируемость? ИИ помещает эти компромиссы в быструю электронную таблицу. Например, для функции «отправить уведомление» вы можете обсудить, использовать ли синхронный (отправка по запросу) или асинхронный (очередь, отправка в фоновом режиме) подход.
Подсказка для сравнения дизайна: «Я разрабатываю функцию «отправить пользователю уведомление по электронной почте». Сравните два подхода: (A) синхронная доставка во время HTTP-запроса, (B) асинхронная доставка в фоновом режиме путем помещения ее в очередь сообщений. Составьте таблицу по следующим осям: время ожидания пользователя, отказоустойчивость, сложность, стоимость инфраструктуры, сложность отладки. Подведите итог в двух предложениях, какой из них я бы выбрал в конечном итоге и в каком случае. Не принимайте решение за меня».
ось
синхронная передача
Асинхронный (очередь)
Время ожидания пользователя
Долго (ожидание отправки)
Короткий (возвращается немедленно)
Отказоустойчивость
Низкий (запрос разрывается, если отправка прерывается)
Высокий (возможна повторная попытка)
сложность
низкий
Средне-высокий (инфраструктура очередей)
Стоимость инфраструктуры
низкий
Требуются дополнительные компоненты
Где это подходит
Низкий объем, простое применение
Большой объем, критическая доставка
Совет: если вы скажете ИИ «не принимайте решение за меня, просто покажите мне варианты и условия», это заставит вас задуматься и снизит риск слепого принятия предложения. Лучшее дизайнерское решение — это решение, принятое человеком, который знает ваш контекст (вами).
Слабая подсказка/Сильная подсказка
СЛАБЫЕ: «Разработать базу данных для системы заказов». (Результат: какой масштаб, какие связи, какие ограничения непонятны; общая, нереальная схема.) СИЛЬНО: «Предложите черновик модели данных для небольшого интернет-магазина. Сущности: Клиент, Заказ, Товар, Товар. Ограничения: в заказе может быть много товаров; цена товара может меняться со временем, но текущая цена должна сохраняться в прошлом заказе; ожидается ~500 заказов в день. Взаимосвязи и почему» Объясните, что вы приняли решение. Укажите, как вы решили задачу истории цен. Предоставьте это в виде списка сущностей и полей, а не кода».
Отличие мощной подсказки; масштаб (500 заказов в день), бизнес-правило (должна сохраняться прошлая цена) и желаемый формат вывода. Одно-единственное предложение типа «Прошлая цена должна быть сохранена» полностью меняет дизайн; Если вы этого не укажете, ИИ выдаст неточную, но правдоподобную диаграмму.
Мини-кейсы
Случай 1 — Скрытое предположение. Команда напрямую кодирует запрос «пользователь может загрузить фотографию профиля». Другая команда спросила ИИ о неопределенности: «Максимальный размер? Разрешенные форматы? Неподходящий контроль контента? Удалить старую фотографию?» Он производит 8 вопросов типа. Первая команда узнает о проблеме в производстве, когда файлы размером 20 МБ заполняют сервер; Вторая команда решает ее в дизайне.
Случай 2 — Неверное предположение о масштабе. ИИ предлагает сложный уровень кэширования для функции отчетности. Когда инженер указывает, что реальные данные составляют всего 30 отчетов в день, ИИ упрощает предположение. Отсутствие указания масштаба влечет за собой ненужную сложность; указание экономит 2 недели ненужной работы.
Случай 3. Разрыв в критериях приемки. «Что произойдет, если платеж не пройдет?» Поскольку вопрос никогда не задавался, система заказов все равно пометит заказ как «подтвержденный» в случае неуспешной оплаты. Список негативных сценариев, созданных ИИ, отражает этот пробел; Критерии приемлемости в 1 строку предотвращают потерю реальных денег.
Распространенные ошибки
- Передача запроса непосредственно в код. Код, написанный до разрешения неоднозначности, быстро решает неправильную проблему.
- Слепое принятие общих «лучших практик» ИИ. Если вы не укажете контекст (масштаб, бюджет, команду), рекомендация вам не подойдет.
- Пропуск нефункциональных требований. Если не указаны скорость, безопасность и масштаб, проект будет неполным.
- Просто думаю о счастливом сценарии. Негативные сценарии, такие как пустые данные, неавторизованный пользователь, статус ошибки, должны быть включены в проект.
- Делегирование принятия решения ИИ. ИИ генерирует варианты; Вы сами решаете, какой компромисс подходит вашему бизнесу.
В итоге
Анализ требований и проектирование — это этап, на котором выявляются самые дешевые ошибки. Здесь ИИ генерирует вопросы, которые выявляют неопределенность, составляет пользовательские истории и критерии приемлемости, а также составляет графики компромиссных решений. Но только вы знаете контекст; Ваша задача — отфильтровать рекомендации ИИ с учетом вашего масштаба, бюджета, команды и юридических ограничений и принять окончательное решение. Дисциплина «не принимайте решение за меня, покажите мне варианты» ведет как к лучшему проектированию, так и к более глубокому обучению.
Задача приложения
Выберите запрос на работу, состоящий из одного предложения, из вашего контекста. Сначала примените к ИИ подсказку о двусмысленности и ответьте на вопросы с учетом ваших реальных ограничений. Затем переведите уточненную потребность как минимум в 2 пользовательские истории и 3 критерия приемки для каждой; Включите хотя бы один негативный сценарий. Наконец, создайте таблицу сравнения проектных решений (синхронный/асинхронный, структура таблицы и т. д.) и напишите собственное решение в 2 предложениях.
контрольный список
- [ ] Я удалил неясности в виде вопросов перед передачей запроса в код.
- [ ] Я дал ИИ контекст (масштаб, полномочия, производительность, юридические ограничения).
- [ ] Я разбил пользовательские истории на проверяемые критерии приемки.
- [ ] Я добавил как минимум один сценарий снижения/преимущества.
- [ ] Я оценил проектное решение с помощью таблицы компромиссов.
- [ ] Я принял окончательное решение, основываясь на своем контексте, я не оставлял это на усмотрение ИИ.