مدیر محصول برای booking-platform می‌گوید: «Calendar sync اضافه کنید.» اگر تیم همان جمله را به Ticket فنی تبدیل کند، ممکن است یک API خارجی وصل شود و با این حال مشکل کاربر حل نشود. شاید کاربر فقط می‌خواهد بداند چه زمان‌هایی واقعاً آزاد است؛ شاید هم سازمان اجازهٔ خواندن تقویم شخصی را نمی‌دهد. پیش از انتخاب راه‌حل، باید مسئله‌ای را که قرار است حل شود قابل مشاهده کنیم.
## اهداف یادگیری
پس از این درس می‌توانی یک درخواست راه‌حل‌محور را به Problem brief تبدیل کنی، Outcome و شاخص مشاهده‌پذیرش را بنویسی، Scope و Non-goal را از هم جدا کنی، و محدودیت‌ها و کیفیت‌های لازم را طوری ثبت کنی که انسان و ایجنت یک چیز را بفهمند.
## جای درس در چرخهٔ سرتاسری
چرخهٔ دوره `Elicit → Specify → Slice → Test → Implement → Observe → Verify → Integrate → Learn` است. این درس در Elicit قرار دارد: هنوز Schema، endpoint یا ابزار انتخاب نمی‌کنیم. درس قبل قرارداد وظیفه را معرفی کرد؛ این‌جا ورودیِ هدف و مرز آن قرارداد را از گفت‌وگوی محصول استخراج می‌کنیم. خروجی، Problem brief است؛ در درس‌های بعد facts، decisions و مثال‌های پذیرش آن را کامل می‌کنند.
## Grilling، برچسب غیررسمی برای Elicitation
در این دوره «Grilling» نامی غیررسمی برای Elicitation ساختاریافته است، نه یک استاندارد یا روش رسمی مستقل. منظور، بازجویی از همکار یا زیادکردن تعداد سؤال‌ها نیست. از رویه‌های شناخته‌شدهٔ استخراج نیاز، گفت‌وگو دربارهٔ داستان و تأیید رفتار استفاده می‌کنیم تا ابهام، ریسک و اختلاف معنا زود دیده شود. ISO/IEC/IEEE 29148 نیاز را به فعالیت‌های مهندسی نیاز پیوند می‌دهد؛ 3Cs نیز یادآوری می‌کند که کارتِ نیاز آغاز گفت‌وگوست، نه قرارداد کامل.
درخواست «Calendar sync اضافه کنید» راه‌حل را نام می‌برد، اما دربارهٔ مسئله سکوت می‌کند. پرسش شروع‌کننده این است: «کدام شخص، در کدام لحظه، اکنون چه مانعی دارد و بعد از تغییر چه نتیجه‌ای باید ببیند؟» پاسخ خوب به جای «تقویم را وصل کنید» می‌گوید: «منشی باید پیش از پیشنهاد وقت، بازه‌های مشغول پزشک را ببیند تا پیشنهاد ناسازگار کمتر شود.» این جمله هنوز Spec نیست، اما Outcome را از فناوری جدا می‌کند.
Outcome با Output فرق دارد. Output ممکن است «یک دکمهٔ اتصال» یا «یک Job همگام‌سازی» باشد. Outcome تغییری در وضعیت کاربر یا کسب‌وکار است: کاهش پیشنهاد وقتِ غیرقابل‌قبول، کوتاه‌شدن زمان هماهنگی، یا جلوگیری از Double booking. شاخص نباید وعدهٔ خیالی بدهد. مثلاً «در آزمایش با دادهٔ ساختگی، منشی برای پزشک متصل، بازهٔ busy را پیش از تأیید رزرو می‌بیند» قابل مشاهده‌تر از «تجربه بهتر می‌شود» است. اگر سنجش Production هنوز ممکن نیست، Proxy و محدودیتش را بنویس.
## 3Cs: کارت، گفت‌وگو، تأیید
3Cs از Ron Jeffries یک الگوی عملیِ جامعه‌محور است، نه جایگزین استاندارد نیازمندی. **Card** یادآور یک نیاز کوچک و قابل اولویت‌بندی است؛ عمداً همهٔ جزئیات را حمل نمی‌کند. برای reschedule، Card می‌تواند فقط بگوید: «بیمار می‌خواهد وقت خودش را جابه‌جا کند.» اگر Card را قرارداد کامل بدانیم، تیم نه مالک را می‌بیند، نه پنجرهٔ لغو و نه تعارض زمان را.
**Conversation** گفت‌وگوی صاحب‌اختیار محصول، عملیات، امنیت و تیم است که معنای Card را می‌سازد. برای همین Card می‌پرسیم: «مالک رزرو کیست؟ زمان مرجع کدام timezone است؟ در هم‌پوشانی چه چیزی تغییر نمی‌کند؟ بعد از deadline لغو چه authority لازم است؟» Factهای فنی مانند مسیر سرویس یا تست موجود از reconnaissance می‌آیند، اما policy و trade-off از Conversation. خروجی آن Problem brief، سؤال باز و Decision ledger است، نه حدس Agent.
**Confirmation** توافق را به رفتار قابل‌بررسی تبدیل می‌کند. این همان جایی است که acceptance example درس ۷ ارزش دارد: Given یک رزرو ۱۰:۰۰ تا ۱۰:۳۰ برای پزشک ۷ در Tenant A، When مالک همان Tenant زمان ۱۰:۱۵ تا ۱۰:۴۵ را می‌خواهد، Then تعارض گزارش و رزرو قبلی بی‌تغییر می‌ماند. Confirmation «مدیر گفت فهمیدم» نیست؛ مثال پذیرش است که بعداً test و review می‌توانند آن را بررسی کنند. پس مسیر درست Card → Conversation → Confirmation است: کارتِ reschedule، گفت‌وگو دربارهٔ policy، و مثال‌های مجزای موفقیت، تعارض، DST و deadline.
## اجزای Problem brief
یک brief کوتاه، پنج قطعه دارد. **کاربر و موقعیت** می‌گوید چه کسی و در کدام جریان کار درگیر است. **مسئله** مانع فعلی را بدون راه‌حلِ ازپیش‌فرض‌شده بیان می‌کند. **Outcome** تغییر قابل مشاهده را می‌گوید. **Scope** آنچه این تحویل شامل می‌شود را مرزبندی می‌کند. **Non-goal** انتظارهای نزدیک اما خارج از کار را صریح رد می‌کند.
برای مثال، user فقط «پزشک» نیست: «منشی Tenant کلینیک A، هنگام ایجاد رزرو در پنل داخلی» است. چنین دقتی می‌پرسد آیا بیمار هم باید بازه‌ها را ببیند و آیا Tenant B هرگز دادهٔ A را می‌بیند. Scope اولیه می‌تواند «خواندن بازه‌های busy از یک provider آزمایشی برای یک پزشک، نمایش فقط برای منشی و جلوگیری از پیشنهاد همان بازه» باشد. Non-goalها می‌توانند «نوشتن رویداد در تقویم خارجی، همگام‌سازی تاریخی، پشتیبانی از چند provider و تغییر سیاست لغو» باشند. Non-goal شکست یا کم‌کاری نیست؛ دفاع در برابر بزرگ‌شدن بی‌صداست.
**محدودیت** واقعیتی است که گزینه‌ها را تنگ می‌کند: سیاست رضایت کاربر، قرارداد provider، بودجه، تاریخ انتشار، ساختار چندمستأجری یا ممنوعیت نگهداری token. محدودیت با ترجیح فرق دارد. «ظاهر ساده باشد» ترجیح مبهم است؛ «منشی با صفحه‌خوان باید بتواند وضعیت busy را تشخیص دهد» یک کیفیت قابل آزمون است. کیفیت‌هایی مانند حریم خصوصی، کارایی، دسترس‌پذیری و قابلیت اطمینان باید به رفتار یا آستانه تبدیل شوند. «امن باشد» ما را به تصمیم نمی‌رساند؛ «token تقویم هرگز در browser ذخیره نشود و فقط tenant/کاربر مجاز بتواند اتصال خودش را ببیند» نقطهٔ بررسی می‌سازد.
## مثال واقعی: brief برای sync تقویم
نسخهٔ قابل گفت‌وگو:
کاربر: منشیِ یک Tenant، هنگام ساخت رزرو برای پزشک متصل.
مسئله: پیش از انتخاب وقت، بازه‌های مشغول تقویم پزشک دیده نمی‌شود.
Outcome: در محیط آزمایشی، منشی بازهٔ busy را می‌بیند و سامانه پیشنهاد آن بازه را رد می‌کند.
Scope: یک provider آزمایشی، خواندن read-only، یک پزشک، پنل منشی.
Non-goal: نوشتن تقویم، sync تاریخی، چند provider، تغییر سیاست لغو.
محدودیت: رضایت پزشک لازم؛ token در client نگهداری نمی‌شود؛ tenantها جدا هستند.
تصمیم باز: در خطای provider، رزرو block شود، دستی با وضعیت نامشخص ادامه یابد، یا آخرین sync برچسب‌دار استفاده شود؟این brief عمداً سؤال دارد: «busy» شامل رویداد all-day است؟ outage provider چه می‌کند؟ پاسخ‌ها را حدس نمی‌زنیم؛ در ledger درس بعد ثبت می‌کنیم. اما بیان Outcome مانع می‌شود که تیم، webhook یا OAuth را قبل از دانستن ارزش واقعی انتخاب کند.
مثال ضعیف و علت شکست
«OAuth Google Calendar، webhook و صفحهٔ تنظیمات را تا جمعه بسازید؛ هر فایل لازم شد تغییر دهید.» این درخواست هم راه‌حل را قطعی می‌کند، هم Scope نامحدود می‌دهد، هم معیار پایان ندارد. ممکن است ایجنت صفحه و endpoint بسازد، اما معلوم نیست چه کسی مجاز است، چه داده‌ای می‌خوانیم، یا وقتی provider قطع است رزرو چگونه ادامه می‌یابد. تست سبزِ یک callback، Outcome کاربر نیست.
مثال اصلاح‌شده
«برای منشی Tenant A در محیط آزمایشی، امکان مشاهدهٔ بازهٔ busy پزشکِ رضایت‌داده را بررسی کنید؛ فقط جریان read-only را طراحی کنید. قبل از انتخاب provider، Problem brief، گزینه‌های رضایت و Non-goalها را برگردانید. اگر سیاست نگهداری token نامعلوم است، `DECIDE` کنید.» این Prompt راه‌حل را منع نمی‌کند؛ انتخابش را تا بعد از فهم مسئله و تصمیم انسانی عقب می‌اندازد.
## آزمایشگاه: درخواست sync را قاب‌بندی کن
**ورودی:** جملهٔ «Calendar sync اضافه کنید» و Canon رزروِ چندمستأجری. **گام‌ها:** ۱) کاربر و لحظهٔ کار را در یک جمله بنویس. ۲) مسئله و Outcome را بدون نام provider بنویس. ۳) سه مورد Scope و سه Non-goal بساز. ۴) دو محدودیت و دو کیفیت قابل‌بررسی اضافه کن. ۵) یک سؤال تصمیم‌ساز را با برچسب `DECIDE` مشخص کن.
**خروجی مورد انتظار:** brief باید نمایش بازهٔ busy برای منشی، جداسازی Tenant، تصمیمِ بازِ خطای provider و عدم نوشتن تقویم را روشن کند؛ نه اینکه صرفاً فهرست تکنولوژی باشد.
**Recovery:** اگر جمله‌ات با نام API یا database شروع می‌شود، آن را پاک کن و بپرس «کاربر بعد از موفقیت چه چیزی می‌بیند یا نمی‌تواند انجام دهد؟» اگر Outcome قابل مشاهده نیست، نمونهٔ یک تعامل یا معیار Pass/Fail اضافه کن.
## خطاهای رایج و نشانه‌ها
- Output را Outcome خواندن: Ticket با نام ابزار شروع می‌شود و کاربر یا رفتار موفقیت ندارد.
- Scope بدون Non-goal: هر سؤال نزدیک، به‌عنوان «بدیهی» وارد تحویل می‌شود.
- صفت مبهم: «سریع» و «امن» آمده‌اند اما آستانه یا رفتار خطا نیست.
- محدودیت پنهان: طراحی پس از ساختن، با policy رضایت یا مرز Tenant برخورد می‌کند.
- سنجش نمایشی: تعداد endpoint یا خط کد به‌جای تغییر قابل مشاهده گزارش می‌شود.
## چک‌لیست Verification
- [ ] کاربر، لحظهٔ کار و مانع فعلی مشخص‌اند.
- [ ] Outcome بدون نام‌بردن از راه‌حل و با مشاهده یا معیار قابل بررسی نوشته شده است.
- [ ] Scope و Non-goal هر دو صریح‌اند.
- [ ] محدودیت‌ها از ترجیح‌های مبهم جدا شده‌اند.
- [ ] هر کیفیت به رفتار، آستانه یا سناریوی خطا متصل است.
- [ ] سؤال‌های تصمیم هنوز فرضِ پنهان نشده‌اند.
## تمرین مستقل
درخواست «برای بیمار Reminder پیامکی بفرستید» را به Problem brief تبدیل کن.
**Rubric پاسخ:** پاسخ قابل‌قبول کاربر و لحظهٔ کار، Outcome قابل مشاهده، Scope محدود، دست‌کم دو Non-goal، رضایت/هزینه یا حریم خصوصی به‌عنوان محدودیت، و رفتار قابل آزمون برای ارسال ناموفق دارد. پاسخ ضعیف فقط provider پیامک و endpoint را نام می‌برد.
## جمع‌بندی
راه‌حل خواسته‌شده، دادهٔ مفیدی از گفت‌وگوست اما تعریف مسئله نیست. Problem brief با Outcome، Scope، Non-goal، محدودیت و کیفیت، مقصد مشترک می‌سازد. اکنون باید تشخیص دهیم کدام مجهول را ایجنت از مخزن کشف می‌کند و کدام را انسان باید تصمیم بگیرد.
## منابع مستقیم
- [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html) — استاندارد مهندسی نیاز؛ الگوی ایجنتی یا ابزار خاص تجویز نمی‌کند.
- [IIBA — Conduct Elicitation](https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/4-elicitation-and-collaboration/4.2-conduct-elicitation) — راهنمای حرفه‌ای Elicitation؛ جای تصمیم مالک محصول را نمی‌گیرد.
- [Ron Jeffries — Card, Conversation, Confirmation](https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/) — روش جامعه‌محور 3Cs، نه استاندارد رسمی.
- [Agentic Software Development workshop](https://behradz.ir/courses/ai-assisted-software-engineering/) — منبع کارگاهی؛ برای ادعای عمومی مستقل کافی نیست.
به زبان ساده
درخواست‌هایی مثل «Calendar sync بساز» راه‌حل را جلوتر از مسئله قرار می‌دهند. Problem brief باید کاربر، مانع فعلی، Outcome، Scope و Non-goal را روشن کند تا فناوری جای هدف را نگیرد.
مثال واقعی
در سناریوی فرضی دوره، مسئلهٔ منشی این است که پیش از پیشنهاد وقت، بازهٔ busy پزشک را نمی‌بیند؛ این Outcome می‌تواند با یک provider آزمایشی read-only بررسی شود، بدون آنکه اتصال واقعی تقویم از ابتدا قطعی باشد.