سازنده ماتریس تصمیم: یک تصمیم چندگزینهای را به توصیهای وزندار و قابلدفاع تبدیل کنید
چرا این پرامپت اهمیت دارد
Undocumented gut-call decisions get re-litigated the moment results are anything less than perfect, because there's no record of what was actually weighed. A written, weighted analysis with an explicit sensitivity check settles the argument the first time, and gives you a concrete artifact to revisit if the underlying assumptions change, instead of relying on someone's memory of a conversation that happened weeks earlier.
ما از آن برای چه استفاده میکنیم
You're facing a decision with three or more viable options — a vendor selection, an infrastructure migration path, a hiring choice between finalists, a build-versus-buy call — and need to present a recommendation that will hold up when a skeptical stakeholder asks why you didn't pick a different option.
پرامپت
Role: Act as a senior decision-analysis consultant who helps executives and teams make high-stakes, multi-option decisions using structured, defensible frameworks — the kind of analysis that survives being challenged in a leadership meeting. Context: - The decision I'm facing: [DESCRIBE THE DECISION IN 1-2 SENTENCES] - The options I'm considering: [LIST 3-6 OPTIONS, ONE PER LINE] - The criteria that matter for this decision: [LIST 4-8 CRITERIA, e.g. upfront cost, time-to-value, team capacity required, reversibility, strategic fit] - Any hard constraints or dealbreakers: [LIST ANYTHING THAT AUTOMATICALLY DISQUALIFIES AN OPTION, OR WRITE "NONE"] - Who else needs to be convinced by this analysis: [E.G. "MY CO-FOUNDER," "THE BOARD," "MYSELF ONLY"] Task: 1. First, propose a weighting (out of 100 total points) across the criteria I listed, and explain your reasoning for each weight in one sentence. Pause here so I can adjust before you proceed. 2. Score each option against each criterion on a 1-10 scale, with a one-line justification for every score — no unexplained numbers. 3. Calculate the weighted total for each option. 4. Identify the top-scoring option and flag any options that are statistically too close to call (within 5% of each other). 5. Run a sensitivity check: identify which single criterion, if reweighted by plus or minus 15 points, would change the recommended option. State explicitly if this exists — a fragile recommendation should be labeled as such. 6. Write a final recommendation in plain language, including the strongest argument against your own recommendation and why you're making it anyway. Constraints: - Do not silently round close scores into a false sense of certainty — say explicitly when the decision is close. - Do not use vague criteria labels — operationalize each one in half a sentence before scoring. - If any option violates a stated hard constraint, exclude it from scoring entirely and explain why. - Keep the tone analytical and neutral — no cheerleading for any option. Output Format: 1. A markdown table: rows = options, columns = criteria plus weighted total, sorted highest to lowest. 2. A short "How I Weighted This" section (2-4 sentences). 3. A "How Close Is This" section flagging any near-ties or fragile results. 4. A final recommendation paragraph including the steelman case against it.
نتیجه
How I weighted this
I weighted Time-to-Value highest (30 points) because your Friday deadline and board skepticism suggest speed-to-first-results matters more than long-term elegance right now. Risk of Outage (25 points) comes second since you're mid-fundraise and a customer-facing incident would be costly beyond the technical fix. Team Capacity Required (20 points) reflects your 12-person team's limited bandwidth. Reversibility (15 points) and Total Cost Over 12 Months (10 points) round it out — cost matters less than the other three given your current runway.
| Option | Time-to-Value (30) | Risk of Outage (25) | Team Capacity (20) | Reversibility (15) | Cost (10) | Weighted Total |
|---|---|---|---|---|---|---|
| Lift-and-shift | 9 — deployable in 2 weeks with minimal refactoring | 6 — moves existing fragility as-is, doesn't fix root causes | 8 — low engineering lift | 9 — easy to roll back to on-prem if needed | 5 — higher ongoing cloud spend from unoptimized resources | 78.5 |
| Containerize-and-migrate | 6 — 6-8 week timeline for containerization work | 8 — improves isolation and rollback granularity | 5 — requires Docker/K8s ramp-up for two engineers | 7 — moderately reversible, some rework needed | 7 — better resource utilization | 67.5 |
| Full re-architecture | 2 — 4-6 month timeline, misses your deadline entirely | 9 — addresses root causes directly | 2 — consumes most of the team's bandwidth for two quarters | 3 — hard to reverse once started | 8 — best long-term unit economics | 44.5 |
How close is this
This isn't close — lift-and-shift leads containerize-and-migrate by 11 points, well outside the 5 percent fragility threshold. The one criterion that could flip the recommendation is Time-to-Value: if you reweighted it down by 15 points (to 15) and shifted that weight to Risk of Outage, containerize-and-migrate would edge ahead by roughly 3 points. Worth flagging to your board member if they push back on speed as the top priority.
Recommendation
Go with lift-and-shift for this cycle. The strongest argument against this: it doesn't fix any of the architectural problems that got you here, and you'll likely be having this exact conversation again in 9-12 months once traffic grows. But given your Friday deadline and board skepticism, a working migration you can demo now is worth more than a better migration you can't show yet. Plan the containerize-and-migrate path as your Q2 follow-up, not a competing option for this decision.
اکثر تصمیمات پرمخاطره با گزینههای متعدد بر اساس حس درونی گرفته میشوند که لباس تحلیل پوشیده — یک مدیر گزینهای را که «درست بهنظر میرسید» انتخاب میکند، سپس اگر کسی بپرسد، توجیهی مهندسیمعکوس میسازد. این کار تا زمانی که تصمیم اشتباه از آب درنیاید خوب پیش میرود، و آنوقت هیچ سندی از آنچه واقعاً سنجیده شده وجود ندارد، و گفتگو به «چرا فلان گزینه را در نظر نگرفتیم» بدون پاسخ خوب تبدیل میشود.
چرا این پرامپت به این شکل ساختار یافته
این پرامپت از مدل میخواهد ابتدا وزنها را پیشنهاد دهد و پیش از امتیازدهی به هر چیزی، برای تأیید مکث کند. این ترتیب اهمیت دارد: اگر وزندهی و امتیازدهی در یک مرحله انجام شود، آسان است که یک مدل (یا یک فرد) ناخودآگاه وزنهایی مهندسیمعکوس کند که پاسخی را که از قبل میخواسته تولید کنند. جدا کردن این مراحل باعث میشود منطق وزندهی بهطور مستقل و قابلدفاع باشد، صرفنظر از اینکه کدام گزینه در نهایت برنده میشود.
مرحلهای که اکثر چارچوبها آن را نادیده میگیرند
بررسی حساسیت — شناسایی اینکه کدام معیار منفرد، اگر با ±۱۵ امتیاز مجدداً وزندهی شود، توصیه را برعکس میکند — چیزی است که این را از یک قالب امتیازدهی ثابت متمایز میکند. اکثر ماتریسهای تصمیم یک عکس فوری در یک لحظه زمانی ارائه میدهند و اطمینان کاذب القا میکنند. تصمیمی که نزدیک است و با یک بازنگری متوسط و قابلدفاع برعکس میشود، اساساً متفاوت است از تصمیمی که در طیف وسیعی از وزندهیهای معقول پایدار میماند.
جایی که این پرامپت ارزش خود را نشان میدهد
این برای تصمیمات پیشپاافتاده نیست — انتخاب یک رستوران برای ناهار به یک ماتریس وزندار نیاز ندارد. این برای معدودی تصمیمات چندگزینهای در هر فصل ساخته شده که اشتباه گرفتن آنها هزینهبر است و یک فرآیند مستند بهاندازه پاسخ اهمیت دارد: انتخاب فروشنده، مسیرهای مهاجرت زیرساخت، کاندیداهای رقیب شغلی، تصمیمات ساخت-یا-خرید.