درخت پرسش، ریسک و شرط توقف

درخواست «تقویم را وصل کنید» ده‌ها سؤال می‌سازد. اگر تیم آن‌ها را به ترتیب یادداشت‌برداری بپرسد، ممکن است دو روز دربارهٔ رنگ تقویم حرف بزند و سپس بفهمد نگهداری token از نظر امنیتی ممنوع است. مسئله، کمبود سؤال نیست؛ ترتیب آن‌هاست. درخت Grilling کمک می‌کند سؤال‌های وابسته و پرهزینه پیش از کار ارزان و برگشت‌پذیر پاسخ بگیرند.

## اهداف یادگیری

پس از این درس می‌توانی پرسش‌های Elicitation را به درخت وابستگی تبدیل کنی، frontier ریسک‌اول را انتخاب کنی، برای هر سؤال گزینه و فرض شفاف عرضه کنی، و شرط توقفی بنویسی که Grilling را از گفت‌وگوی بی‌پایان به خروجی آمادهٔ Spec برساند.

## جای درس در چرخهٔ سرتاسری

در Elicit، درس ۴ مسئله و مرز را ساخت و درس ۵ Fact و Decision را جدا کرد. این درس ترتیب تصمیم‌ها را تعیین می‌کند. خروجی آن Question tree، ledger به‌روز و stop condition است. بعد از آن درس ۷ با Rule و مثال، رفتار را قابل آزمون می‌کند؛ هنوز وارد طراحی فنی یا پیاده‌سازی نمی‌شویم.

## Grilling استاندارد نیست، اما بی‌قاعده هم نیست

«Grilling» در این دوره برچسبی غیررسمی برای Elicitation ساختاریافته است، نه استانداردی با مراحل اجباری. منابعی مانند ISO 29148 و راهنمای IIBA، Elicitation را فعالیتی شناخته‌شده می‌دانند؛ الگوی سوال‌محور community مانند `grill-me` می‌تواند برای کار با Agent مفید باشد، اما اعتبار یک استاندارد یا اثبات مستقل اثربخشی ندارد. بنابراین از نام جذاب روش، مجوز فشارآوردن به ذی‌نفع یا تولید سؤال‌های بی‌پایان نمی‌سازیم.

درخت پرسش از یک **تصمیم ریشه** شروع می‌کند، نه از فهرست فناوری. برای sync، ریشه ممکن است «آیا سامانه برای پیشنهاد وقت به availability خارجی تکیه می‌کند؟» باشد. پاسخ آن، فرزندهایی می‌سازد: رضایت و نقش مجاز، سطح دادهٔ قابل نمایش، رفتار outage، مرجع timezone، provider، سپس جزئیات UI و retry. هر یال می‌گوید پاسخ پدر، معنی یا امکان پاسخ فرزند را تغییر می‌دهد. تا وقتی معلوم نیست read-only هستیم یا نه، بحث webhook یا conflict resolution زودرس است.

*نمودار نشان می‌دهد که پرسش‌های سیاست و ریسک پیش از گزینه‌های فنی و جزئیات اجرا قرار می‌گیرند.*

## وابستگی را صریح کن

یک پرسش را با چهار جزء بنویس: **تصمیم**، **چرا اکنون**، **گزینه‌های توصیه‌شده** و **اثر پاسخ**. برای نمونه:

Q1: در outage تقویم، ایجاد رزرو چگونه ادامه یابد؟
چرا اکنون: رفتار، Acceptance examples و طراحی خطا را عوض می‌کند.
گزینه‌ها: A) جلوگیری از رزرو؛ B) رزرو دستی با وضعیت نامشخص؛ C) آخرین sync با برچسب کهنگی.
پیشنهاد: B برای MVP، چون availability را قطعی جا نمی‌زند و مسیر خدمت را حفظ می‌کند.
اثر: مثال‌ها، Copy، audit و نیاز به timestamp sync.
وابسته به: تعریف Scope read-only و نقش منشی.

«پیشنهاد» پاسخ را تحمیل نمی‌کند. ارزشش این است که هزینهٔ فکرکردن را کم و trade-off را قابل اعتراض می‌کند. گزینهٔ توصیه‌شده باید دلیل و نقطهٔ شکست داشته باشد. اگر گزینه C انتخاب شد، باید تصمیم بگیریم stale تا چند دقیقه است؛ اگر A انتخاب شد، پشتیبانی و تجربه بیمار چه می‌کند. پیشنهاد بدون پیامد، فشار پنهان است.

## frontier ریسک‌اول

در هر لحظه، همهٔ سؤال‌های بی‌وابستگیِ پاسخ‌نداده، frontier هستند. آن‌ها را صرفاً بر اساس آسانی مرتب نکنید. سؤال اولویت‌دار بیشترین ترکیب **بلوک‌کردن کارهای بعدی، برگشت‌ناپذیری، blast radius، ریسک privacy/security، هزینهٔ تأخیر و احتمال تغییر Scope** را دارد. این یک فرمول عددی جهانی نیست؛ تیم می‌تواند سطح کم/میانه/بالا بدهد، اما دلیل اولویت باید نوشته شود.

برای booking-platform، این ترتیب نمونه منطقی است:

۱) آیا پزشک رضایت داده و کدام نقش داده را می‌بیند؟ ریسک privacy و boundary. ۲) outage provider چه می‌کند؟ شرط رفتار و Acceptance. ۳) timezone مرجع چیست؟ داده و مثال‌ها را می‌شکند. ۴) آیا دادهٔ busy فقط read-only است؟ دامنهٔ token و طراحی را عوض می‌کند. ۵) provider و refresh cadence چیست؟ بعد از روشن‌شدن policy. ۶) Copy و ترتیب UI چگونه است؟ برگشت‌پذیرتر.

ممکن است در سازمانی با قرارداد provider نزدیک به انقضا، سؤال provider اول شود. مهم این است که دلیل با ریسک فعلی پیوند داشته باشد، نه اینکه tree را نسخهٔ مقدس بدانیم.

## فرض، تصمیم و سؤال باز

فرض، جملهٔ تأییدنشده‌ای است که فعلاً برای پیش‌رفتن استفاده می‌کنیم: «همهٔ پزشکان timezone کلینیک را می‌پذیرند.» تصمیم، انتخابی است که مالک آن را تأیید کرده: «timezone کلینیک مرجع نمایش MVP است.» سؤال باز، هنوز یکی از این دو نیست. هر سه را جدا نگه دارید. تبدیل فرض به Decision بدون تأیید، همان حدس پنهانی است که Grilling باید حذف کند.

فرض فقط وقتی قابل قبول است که اثر آن کم یا برگشت‌پذیر باشد، owner بداند، deadline تأیید داشته باشد و failure mode نوشته شود. برای privacy، پرداخت، migration یا حذف داده، default مناسب غالباً توقف است، نه فرض خوش‌بینانه. Prompt ایجنت باید بگوید: «فرض‌ها را برچسب بزن؛ اگر به policy یا رفتار پذیرش اثر می‌گذارند، `DECIDE` کن.»

## شرط توقف: چه وقت برای Spec آماده‌ایم؟

هدف Grilling پاسخ‌دادن به همهٔ پرسش‌های ممکن نیست. تیم آمادهٔ رفتن به Spec است وقتی:

• Problem brief، Scope و Non-goal تأیید شده‌اند.
• همهٔ Decisionهای high-risk یا blocking مالک و پاسخ دارند.
• Factهای لازم با شاهد کافی کشف شده‌اند.
• فرض‌های باقی‌مانده کم‌ریسک، برچسب‌دار، deadlineدار و قابل برگشت‌اند.
• Ruleها و مثال‌های پذیرشِ مسیر اصلی و خطا نوشته‌شده‌اند.
• سؤال‌های باقی‌مانده یا خارج از Scope‌اند یا برنامهٔ پیگیری دارند.

این «stopping condition» زمان جلسه را هم مهار می‌کند. مثلاً «حداکثر ۴۵ دقیقه یا تا پاسخ Q1–Q4؛ در نبود پاسخ Q1/Q2 کار BLOCKED و provider انتخاب نمی‌شود.» توقف، شکست همکاری نیست؛ حفاظت از تیم در برابر شروع‌کردن با authority نامعلوم است.

## مثال واقعی: درخت برای Calendar availability

ریشه: «availability خارجی چه نقشی در ایجاد رزرو دارد؟» شاخهٔ policy: رضایت پزشک → نقش منشی → سطح نمایش busy/free. شاخهٔ reliability: outage → مسیر دستی یا block → پیام به بیمار و audit. شاخهٔ time: timezone مرجع → all-day → DST و بازه‌های نیمه‌شب. شاخهٔ technical: read-only → provider → token boundary → refresh. شاخهٔ UI: فقط بعد از پاسخ بالا، نمایش، Copy و filter.

در frontier اول، رضایت، outage و timezone قرار دارند. گزینهٔ B برای outage فقط پیشنهاد است و تا تأیید مشترک مالک محصول و عملیات، رفتار پذیرفته‌شده نیست. اگر پاسخ ندهند، provider انتخاب نمی‌شود و تیم `DECIDE/BLOCKED` را با اثر هر سه گزینه ثبت می‌کند؛ چون UI و retry بر رفتاری نامعلوم ساخته می‌شوند.

مثال ضعیف و علت شکست

«بیست سؤال دربارهٔ sync بپرس و پس از پاسخ همه شروع کن.» تعداد، کیفیت یا ترتیب نیست. ذی‌نفع ممکن است از سؤال‌های جزئی خسته شود، پاسخ policy حساس را عقب بیندازد و تیم هیچ معیار توقف نداشته باشد. نسخهٔ دیگر، پرسیدن «چه می‌خواهید؟» بدون گزینه است؛ هزینهٔ تحلیل را کامل به انسان برمی‌گرداند.

مثال اصلاح‌شده

«از brief و ledger، یک tree بساز. فقط frontier بدون وابستگی را نشان بده و برای هر سؤال high-risk، سه گزینه با پیامد و یک پیشنهاد قابل رد ارائه کن. Qهای privacy، outage و timezone را قبل از provider بیاور. پس از پاسخ آن‌ها، Rule/Example آماده کن؛ اگر owner تا فردا پاسخ نداد، BLOCKED با default ثبت کن.»

## آزمایشگاه: frontier را رتبه‌بندی کن

**ورودی:** brief تقویم و چهار Decision باز: رضایت، outage، timezone و provider. **گام‌ها:** ۱) ریشه و یال‌های وابستگی را بکش. ۲) برای هر سؤال، بلوک‌کنندگی، برگشت‌ناپذیری و privacy را کم/میانه/بالا برچسب بزن. ۳) frontier اول را با دلیل مرتب کن. ۴) برای دو سؤال گزینه، پیشنهاد و اثر بنویس. ۵) شرط توقف ۴۵دقیقه‌ای و رفتار `BLOCKED` را ثبت کن.

**خروجی مورد انتظار:** رضایت، outage و timezone پیش از provider هستند؛ پیشنهادها policy را پنهان نمی‌کنند و سؤال‌های باقی‌مانده مالک یا Scope دارند.

**Recovery:** اگر همهٔ پرسش‌ها «بالا» هستند، آن‌ها را به اثر مشخص بشکن: امنیت، داده، زمان یا Scope. اگر چرخهٔ وابستگی ساختی، تصمیم بالادستی مشترک را پیدا کن یا برای آن `DECIDE` جدید بساز.

## خطاهای رایج و نشانه‌ها

• مرتب‌سازی با آسانی: UI کامل شده اما policy token نامعلوم است.
• درخت خطی: پاسخ یک سؤال مسیر سؤال بعدی را عوض نمی‌کند.
• گزینهٔ جعلی: همهٔ گزینه‌ها جز یکی بد نوشته شده‌اند.
• فرض بی‌نام: در Spec ظاهر می‌شود ولی owner و deadline ندارد.
• توقف نداشتن: جلسه با سؤال‌های کم‌اثر ادامه دارد یا تیم با ریسک باز code می‌زند.

## چک‌لیست Verification

• [ ] Grilling را نام غیررسمیِ مبتنی بر Elicitation معرفی کرده‌ام.
• [ ] هر سؤال تصمیم، وابستگی و اثر پاسخ دارد.
• [ ] frontier با ریسک و بلوک‌کنندگی، نه تعداد سؤال، مرتب شده است.
• [ ] گزینه، پیشنهاد و trade-off از authority مالک جدا هستند.
• [ ] فرض‌ها برچسب، owner، deadline و failure mode دارند.
• [ ] شرط توقف، معیار آماده‌بودن برای Spec و حالت BLOCKED را روشن می‌کند.

## تمرین مستقل

برای «امکان reschedule رزرو» یک Question tree با شش سؤال، دو dependency و stopping condition بنویس.

**Rubric پاسخ:** پاسخ خوب conflict با رزرو دیگر، پنجرهٔ لغو، timezone و نقش مجاز را پیش از Copy UI می‌آورد؛ برای دو سؤال گزینه و پیامد می‌دهد؛ و شرطی دارد که بدون policy مالی یا مالک، Spec را BLOCKED کند. فهرست پرسش بدون یال یا اولویت کافی نیست.

## جمع‌بندی

درخت Grilling نقشهٔ authority و ریسک است، نه فرم اجباری. با frontier ریسک‌اول، تیم زودتر تصمیم‌های پرهزینه را می‌بیند؛ با فرض‌های برچسب‌دار و شرط توقف، گفت‌وگو به موقع تمام می‌شود. اکنون می‌توانیم تصمیم‌ها را به Ruleها و مثال‌هایی تبدیل کنیم که رفتار را قابل آزمون می‌کنند.

## منابع مستقیم

• [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html) — مرجع مهندسی نیاز؛ Grilling را استاندارد نمی‌نامد.
• [IIBA — Conduct Elicitation](https://www.iiba.org/knowledgehub/business-analysis-body-of-knowledge-babok-guide/4-elicitation-and-collaboration/4.2-conduct-elicitation) — راهنمای Elicitation و همکاری.
• [Matt Pocock — grill-me](https://github.com/mattpocock/skills/blob/main/docs/productivity/grill-me.md) — روش community برای گفت‌وگوی نیاز؛ نه استاندارد یا ارزیابی مستقل.

به زبان ساده

درخت پرسش کمک می‌کند سؤال‌های پرریسک و وابسته پیش از جزئیات ارزان UI پاسخ بگیرند. شرط توقف هم مشخص می‌کند چه زمانی با تصمیم‌های باز باید `BLOCKED` یا `DECIDE` شد.

مثال واقعی

برای تقویم در سناریوی فرضی دوره، رضایت پزشک، رفتار outage و timezone باید پیش از انتخاب provider روشن شوند؛ رنگ دکمه تا وقتی این policyها نامعلوم‌اند، گرهٔ مهمی نیست.