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