تصمیم‌گیری فناوری با نقشه‌ی سناریو

با یک جدول شروع کنید، نه با یک پیش‌بینی.

این یک نقشه‌ی انتخاب سناریو است. ادعا نمی‌کند پیش‌بینی می‌کند کدام ردیف رخ می‌دهد. تیم مدیریت را وادار می‌کند ببیند هر گزینه وقتی چند آینده‌ی محتمل با یک تصمیم روبه‌رو می‌شوند، چطور رفتار می‌کند.

بیشتر پیشنهادهای فناوری در یک آینده‌ی دلخواه ارائه می‌شوند. فروشنده پایدار می‌ماند. استفاده طبق برنامه رشد می‌کند. مهندسان گردش‌کار را می‌پذیرند. یکپارچه‌سازی همان زمانِ مورد انتظار را می‌برد. خروجی هوش مصنوعی مفید است، بازبینی سریع است و هزینه‌ی عملیاتی در صفحه‌گسترده جا می‌شود. اگر آن آینده برسد، گزینه‌ی پیشنهادی بدیهی به نظر می‌رسد.

انتخاب‌های پرپیامد سزاوار آزمون سخت‌تری‌اند. کار، انتخاب تعهدی است که در بیش از یک مجموعه‌ی شرایطِ باورپذیر قابل‌قبول بماند، و دانستن این‌که کدام شاهد تغییرش را توجیه می‌کند.

نقشه‌ی سناریو انتخاب را می‌آزماید، نه تخیل تیم را

برنامه‌ریزی سناریو وقتی گروهی آینده‌هایی نمایشی ابداع می‌کند که هیچ اثری بر تصمیم ندارند، به نمایش تبدیل می‌شود. یک نقشه‌ی مفید محدودتر است. فقط شرایطی را تغییر می‌دهد که می‌توانند گزینه‌ی ترجیحی را عوض کنند.

برای یک ابتکار برنامه‌نویسی با هوش مصنوعی، این شرایط می‌توانند این‌ها باشند:

• این‌که چه مقدار کارِ تکمیل‌شده و پذیرفته‌شده تغییر می‌کند، نه این‌که چه مقدار کد تولید می‌شود؛
• این‌که آیا ظرفیت بازبینی، آزمون و امنیت می‌تواند خروجی تازه را جذب کند؛
• این‌که آیا تیم‌ها آن‌قدر پیوسته از ابزار استفاده می‌کنند که کار پلتفرمی را توجیه کند؛
• این‌که آیا کد منبع، پرامپت‌ها و داده‌های پایش درون مرزهای تأییدشده می‌مانند؛
• این‌که آیا قیمت، رفتار مدل یا شرایط محصولِ ارائه‌دهنده تغییر می‌کند؛
• این‌که آیا مهندسان فهم لازم برای مالکیت و تعمیر نتیجه را حفظ می‌کنند.

شواهد فعلی به مدیران دلیل می‌دهد که این‌ها را بده‌بستان‌های واقعی بدانند. تحلیل مارس ۲۰۲۶ گروه DORA درباره‌ی استفاده از هوش مصنوعی در چرخه‌ی تحویل نرم‌افزار پذیرش بیشتر هوش مصنوعی را هم با بهره‌دهی بیشتر در تحویل و هم با ناپایداری بیشتر تحویل مرتبط می‌داند. همچنین اشاره می‌کند که زمانی که در تولید صرفه‌جویی می‌شود، می‌تواند به شکل کار ممیزی و وارسی برگردد. پس «خروجی بیشتر» و «تحویل بهتر» به خانه‌های متفاوتی از نقشه تعلق دارند.

سناریوها باید باورپذیر، متمایز و مرتبط با تصمیم باشند. به اسم‌های سینمایی یا بیست متغیر نیاز ندارند. اغلب سه حالت کافی است:

• قابل‌مدیریت: فرض‌های مهم به‌طور کلی مساعدند.
• سخت: یک یا دو سود مورد انتظار، با اصطکاک عادیِ عملیات تضعیف می‌شوند.
• مختل‌کننده: یک وابستگی، ریسک یا محدودیتِ مهم تغییر می‌کند.

واژه‌ها مهم‌اند. «بهترین، مورد انتظار و بدترین» آدم‌ها را به دفاع از یک پیش‌بینی تشویق می‌کند. «قابل‌مدیریت، سخت و مختل‌کننده» می‌پرسد آیا گزینه همچنان قابل‌اداره است.

دور تصمیم مرز بکشید

«آیا ایجنت‌های برنامه‌نویسی را به کار بگیریم؟» بزرگ‌تر از آن است که بشود درباره‌اش تصمیم گرفت. مجوزها، دسترسی به داده، هویت، مخزن‌های تأییدشده، انتخاب وظایف، آموزش، بازبینی، ارزیابی، پشتیبانی و خریدهای آینده را در خود دارد. آدم‌ها می‌توانند با این جمله موافق باشند، در حالی که تعهدهای کاملاً متفاوتی را در ذهن دارند.

جمله‌ی تصمیم به پنج جزء نیاز دارد:

تصمیم می‌گیریم که آیا این مالک باید این سطح از تعهد را برای این جمعیت و این گردش‌کار، در این دوره و درون این مرزها مجاز کند.

برای نمونه:

تیم مدیریت مهندسی تصمیم می‌گیرد که آیا یک برنامه‌ی دوازده‌هفته‌ایِ داوطلبانه‌ی ایجنت برنامه‌نویسی را برای چهار تیم محصول، محدود به مخزن‌های تأییدشده و بدون تغییر در کنترل‌های فعلی بازبینی و انتشار، تأمین بودجه کند.

این جمله پاسخ را تعیین نمی‌کند. چیزی می‌سازد که سناریوها بتوانند بیازمایندش.

یک جایگزین واقعی را هم حفظ می‌کند. «پلتفرم را بپذیریم» در برابر «عقب بمانیم» مجموعه‌ی گزینه نیست. یک مقایسه‌ی جدی می‌تواند شامل استقرار گسترده، یک برنامه‌ی هدفمند، یک آزمایش داخلیِ کوچک‌تر، بهبود گردش‌کار بدون ابزار تازه‌ی هوش مصنوعی و عدم تعهد در فصل جاری باشد.

گزینه‌ی «بدون تغییر» هم باید پیامدهایش را حمل کند. تأخیرهای فعلی در بازبینی، استفاده از ابزارهای تأییدنشده، نوسازی کند و هزینه‌ی فرصت، فقط چون مدیریت یک پیشنهاد را رد می‌کند ناپدید نمی‌شوند. بی‌عملی گزینه‌ای با پیامد است، نه یک خط پایه‌ی خنثی.

پیش از تعیین میزان اطمینان، پیامدها را مقایسه کنید

تیم‌ها اغلب از گزینه‌ها مستقیم به احتمال می‌پرند: ۷۰ درصد احتمال موفقیت، برآورد هزینه با اطمینان بالا، نمره‌ی ریسک ۳٫۸. دقت تحلیلی به نظر می‌رسد، اما یک عدد می‌تواند اختلاف درباره‌ی معنای «موفقیت» را پنهان کند.

اول ابعاد پیامد را ترسیم کنید:

بعد بازه‌ها و کیفیت شواهد را توصیف کنید. هزینه‌ی مجوز ممکن است قراردادی و باریک باشد. زحمت یکپارچه‌سازی ممکن است بر پایه‌ی نمونه‌ای اولیه با دو تیم باشد و گسترده بماند. بهره‌وری ممکن است با خوداظهاری سنجیده شده باشد، نه کار تکمیل‌شده. رفتار امنیتی ممکن است مستند شده باشد اما در محیط سازمان آزموده نشده باشد.

برچسب‌های ساده‌ای برای شواهد به کار ببرید:

• این‌جا مشاهده‌شده: در گردش‌کار و جمعیت مرتبط سنجیده شده.
• جای دیگر مشاهده‌شده: معتبر، اما از زمینه‌ای دیگر منتقل‌شده.
• برآوردشده: بر پایه‌ی فرض‌های بیان‌شده مدل‌سازی شده.
• ادعاشده: توسط فروشنده، حامی یا تیم ارائه شده، بدون اعتبارسنجی مستقل.
• نامعلوم: مهم و در حال حاضر بی‌پشتوانه.

این برچسب‌ها از یک نمره‌ی اطمینانِ واحد برای کل پیشنهاد مفیدترند. نشان می‌دهند چرا دو نفر با اطمینان یکسان ممکن است به پایه‌های بسیار متفاوتی تکیه کرده باشند.

با بازار امروز هوش مصنوعی هم جور درمی‌آیند. بخش عملکرد فنیِ گزارش AI Index ۲۰۲۶ دانشگاه استنفورد گزارش می‌دهد که مدل‌های برتر در رتبه‌بندی‌های کلیِ ترجیح کاربران به هم نزدیک‌تر می‌شوند و تمایز به سمت هزینه، قابلیت اطمینان و عملکرد در حوزه‌های تخصصی می‌رود. همین گزارش اشاره می‌کند که ایجنت‌ها هنوز در سهم قابل‌توجهی از تلاش‌ها در بنچمارک‌های ساخت‌یافته‌ی کار با کامپیوتر شکست می‌خورند. یک جدول رده‌بندیِ عمومی نمی‌تواند یک تصمیم عملیاتی را فیصله دهد. شواهد باید با وظیفه، پیامد و شرایط سازمان جور باشد.

ترجیحات باید ثبت شوند

واقعیت‌ها به‌تنهایی انتخاب نمی‌کنند. مدیران درباره‌ی این‌که کدام سود مهم است، کدام بار قابل‌قبول است و چه کسی باید پیامد منفی را بپذیرد، داوری ارزشی هم می‌کنند.

فرض کنید یک برنامه‌ی هدفمندِ ایجنت برنامه‌نویسی احتمالاً سرعت تحویل را اندکی بهتر می‌کند. در عین حال بازبینی امنیتیِ بیشتری می‌سازد، شیوه‌ی یادگیری مهندسان تازه‌کار را تغییر می‌دهد و وابستگی به یک ارائه‌دهنده را بیشتر می‌کند. انتخاب نهایی تا حدی به ترجیحات سازمان بستگی دارد:

• آیا تحویل سریع‌تر قابلیت‌ها به ظرفیت بازبینیِ اضافه می‌ارزد؟
• آیا شرکت حاضر است برای یادگیری زودتر، هزینه‌ی جایگزینی را بپذیرد؟
• آیا همه‌ی تیم‌ها باید یک ابزار را دریافت کنند، یا دسترسی نابرابر در دوره‌ی آزمایش قابل‌قبول است؟
• تیم‌ها درون یک مرز امنیتیِ مشترک چقدر باید خودمختار باشند؟
• کدام شکست‌ها به تأیید انسانی نیاز دارند، حتی اگر خودکارسازی را محدود کند؟
• وقتی بهره‌وری محاسبه می‌شود، بار کاریِ چه کسی به حساب می‌آید؟

پنهان کردن این پرسش‌ها در یک کارنامه‌ی وزن‌دار آن‌ها را عینی نمی‌کند. فقط بررسی ترجیحات را سخت‌تر می‌کند.

کنار نقشه‌ی سناریو یک «دفتر ترجیحات» کوچک بنویسید:

این پیوستی اخلاقی نیست. بخشی از تصمیم است. اگر سلسله‌مراتب ارزش‌ها تغییر کند، گزینه‌ی ترجیحی ممکن است تغییر کند، حتی وقتی همه‌ی پیش‌بینی‌ها ثابت می‌مانند.

هسته‌ی چارچوب مدیریت ریسک هوش مصنوعی NIST، ترسیم زمینه را پایه‌ی فهم اثرات، تحمل ریسک و این‌که آیا یک سامانه‌ی هوش مصنوعی اصلاً مناسب است می‌داند. کارکرد «نگاشت» در این چارچوب یادآوری مفیدی است که ریسک را نمی‌شود از آدم‌ها، محیط، هدف و پیامدهای پیرامون سامانه جدا کرد. نقشه‌ی سناریو این ایده را عملیاتی می‌کند، با نشان دادن این‌که در هر شرایط کدام گروه‌ها سود می‌برند و کدام‌ها در معرض ریسک قرار می‌گیرند.

دنبال برنده‌های شکننده بگردید

پس از پر شدن نقشه، فوراً از ستون‌ها میانگین نگیرید. اول شکنندگی را شناسایی کنید.

گزینه‌ای شکننده است که فقط وقتی برنده می‌شود که چند فرض نامطمئن هم‌زمان مساعد باشند. یک استقرار گسترده ممکن است به پذیرش بالا، زحمت وارسیِ کم، شرایط پایدار ارائه‌دهنده، ظرفیت بازبینی کافی و نبودِ افزایش معنادار در حوادث نیاز داشته باشد. هر فرض به‌تنهایی شاید معقول به نظر برسد. ترکیبشان می‌تواند گزینه را خیلی کم‌دوام‌تر از آنچه توجیه اقتصادی‌اش نشان می‌دهد کند.

چهار آزمون را به کار ببرید:

برتری مطلق: آیا یک گزینه در همه‌ی شرایط ترسیم‌شده دست‌کم به‌اندازه‌ی گزینه‌ی دیگر قابل‌قبول است؟ اگر چنین است، گزینه‌ی ضعیف‌تر برای ماندن به دلیلی ویژه نیاز دارد.

آستانه: کدام متغیرِ منفرد انتخاب را برمی‌گرداند؟ می‌تواند زمان اصلاح، پذیرش، هزینه‌ی مهاجرت، نرخ حوادث یا ظرفیت بازبینیِ لازم باشد.

پشیمانی: اگر تصمیم اشتباه باشد، مدیریت بیش از همه آرزو می‌کند کدام زیان را مهار کرده بود؟ پشیمانی می‌تواند از یادگیریِ ازدست‌رفته، یک مواجهه‌ی امنیتیِ قابل‌پیشگیری، وابستگی پرهزینه، زمان ازدست‌رفته یا آسیب به اعتماد بیاید.

بازیابی: سازمان با چه سرعتی می‌تواند تعهد را محدود، برگردان یا جایگزین کند؟ انتخابی با سود مورد انتظارِ کمی پایین‌تر، اگر بازیابی را مقرون‌به‌صرفه نگه دارد، می‌تواند قوی‌تر باشد.

این کار گفت‌وگو را از «کدام گزینه بیشترین مجموع را دارد؟» به «کدام گزینه آبرومندانه شکست می‌خورد و کدام به همکاری دنیا نیاز دارد؟» می‌برد.

دوام همیشه به معنای انتخاب کوچک‌ترین حرکت نیست. مهاجرتی که به تعویق افتاده، وقتی فروشنده پشتیبانی را قطع می‌کند می‌تواند خطرناک‌تر باشد. یک پایلوت باریک وقتی یک کنترل امنیتی باید در کل سازمان استاندارد شود، می‌تواند ناکافی باشد. نقشه باید این موارد را آشکار کند، نه این‌که مکانیکی به احتیاط پاداش دهد.

شاهدی بخرید که گزینه‌ها را از هم جدا کند

یک واقعیتِ غایب فقط وقتی سزاوار پژوهش است که پاسخش بتواند رتبه‌بندی یا سطح ایمن تعهد را تغییر دهد.

برای تصمیم ایجنت برنامه‌نویسی، یک نظرسنجی رضایت عمومی جداسازیِ ضعیفی فراهم می‌کند. تیم‌ها ممکن است از یک ابزار لذت ببرند در حالی که پایداری تحویل کم می‌شود. شواهد تمایزدهنده‌تر می‌تواند از این‌ها بیاید:

• مقایسه‌ی زمان چرخه‌ی کار پذیرفته‌شده میان تیم‌های شرکت‌کننده و تیم‌های مشابهِ غیرشرکت‌کننده؛
• سنجش مدت بازبینی، دوباره‌کاری، نقص‌های فرارکرده و شکست تغییرات در کنار خروجی؛
• آزمودن مدیریت داده و مرزهای مخزن با تیم امنیت؛
• نمونه‌گیری از تغییرات تولیدشده تا ببینیم آیا نگهدارندگان می‌توانند توضیحشان دهند و تعمیرشان کنند؛
• مدل‌سازی هزینه در استفاده‌ی عادی، رشد فراخوانی ابزارها و تغییر قیمت ارائه‌دهنده؛
• خروجی گرفتن از پرامپت‌ها، سیاست‌ها و موارد ارزیابی تا ببینیم آیا خروج عملی است.

هر آزمون باید به یک خانه از نقشه اشاره کند. اگر زحمت بازبینی در کار معرف زیر آستانه‌ی توافق‌شده بماند، سناریوی سخت کمتر نگران‌کننده می‌شود. اگر مهندسان بدون ابزار نتوانند تغییرات تولیدشده را نگهداری کنند، پیامدِ آدم‌ها و توانمندی بدتر می‌شود. اگر خروجی گرفتن ناقص باشد، سناریوی مختل‌کننده گران‌تر می‌شود.

این روش مکمل قرارداد عدم‌قطعیت برای تیم‌های فنی است. آن چارچوب به تیم کمک می‌کند تا وقتی شواهد ناقص است، اقدام را محدود کند. نقشه‌ی سناریو نقش مشخص‌تری دارد: آشکار کند کدام شاهد میان گزینه‌های رقیب تمایز می‌گذارد و کدام گزینه وقتی شرایط جابه‌جا می‌شود قابل‌قبول می‌ماند.

یک نقطه‌ی توقف هم وجود دارد. وقتی پژوهش بیشتر دیگر نتواند انتخاب یا مرزش را تغییر دهد، ساعت تصمیم برای پایان دادن به فلج تحلیلی به کار می‌آید. نقشه‌ی سناریو باید پژوهش بی‌هدف را کوتاه کند، نه این‌که یک واحد پیش‌بینیِ دائمی بسازد.

پیش از رسیدن نتیجه، استدلال را ثبت کنید

سابقه‌ی تصمیم باید استدلال را در لحظه‌ی تعهد ثبت کند:

• جمله‌ی تصمیم و مالک آن؛
• گزینه‌های بررسی‌شده، از جمله «بدون تغییر»؛
• سه حالت تصمیم؛
• ابعاد پیامد و برچسب‌های شواهد؛
• ترجیحات و مرزهای غیرقابل‌مذاکره؛
• فرض‌های شکننده و آستانه‌های برگشت؛
• شواهدی که هنوز غایب است؛
• تعهد انتخاب‌شده و دلیل این‌که به‌اندازه‌ی کافی بادوام است؛
• تاریخ یا رویدادی که انتخاب را دوباره باز می‌کند.

سابقه‌ی اولیه را دست‌نخورده نگه دارید. شواهد بعدی باید پیوست شوند، نه این‌که برای تمیز کردن عدم‌قطعیتِ قبلی به کار بروند. نتیجه‌ی مطلوب نباید اطمینان اولیه را قوی‌تر جلوه دهد. نتیجه‌ی ناامیدکننده نباید دلایلی را پاک کند که نشان می‌داد یک آزمایش محدود، انتخابی مسئولانه بوده است.

راهنمای جداگانه‌ی ارزیابی تصمیم‌های هوش مصنوعی بدون سوگیری نتیجه توضیح می‌دهد پس از مشخص شدن نتایج، چطور استدلال را بازبینی کنیم. نقشه‌ی سناریو به آن بازبینی چیزی صادقانه برای بررسی می‌دهد. بدون سابقه‌ای هم‌زمان با تصمیم، یک بازنگری به‌راحتی به رقابت میان حافظه‌ها تبدیل می‌شود.

یک بیانیه‌ی تصمیمِ فشرده می‌تواند این‌طور باشد:

برنامه‌ی هدفمندِ دوازده‌هفته‌ای را انتخاب کردیم، چون در گردش‌کارهای معرف شواهد تولید می‌کند و در عین حال مواجهه‌ی امنیتی، بازبینی و خروج را درون کنترل‌های موجود نگه می‌دارد. استقرار گسترده به فرض‌هایی درباره‌ی پذیرش و وارسی وابسته است که هنوز نیازموده‌ایم. اگر زمان چرخه‌ی کار پذیرفته‌شده بدون افزایش شکست تغییرات یا زحمت بازبینیِ ناپایدار بهتر شود، انتخاب را بازنگری می‌کنیم.

این پاراگراف از یک اسلاید تأییدِ پراطمینان ارزشمندتر است. می‌گوید سازمان چه می‌کند، هنوز مدعی چه چیزی نیست و چه چیزی تعهد بعدی را به دست می‌آورد.

نقشه را در یک جلسه‌ی کاری بکشید

نسخه‌ی اول به یک جلسه‌ی طولانی بیرون از شرکت نیاز ندارد.

ده دقیقه برای نوشتن تصمیم محدود و گزینه‌های باورپذیر بگذارید. پانزده دقیقه برای ساختن حالت‌های قابل‌مدیریت، سخت و مختل‌کننده. پانزده دقیقه برای مقایسه‌ی گزینه‌ها در ارزش کسب‌وکاری، تحویل، قابلیت اطمینان، حاکمیت، اقتصاد، آدم‌ها و انعطاف راهبردی. ده دقیقه برای آشکار کردن ترجیحات، پشیمانی‌ها و مرزهای غیرقابل‌مذاکره. ده دقیقه‌ی آخر را صرف انتخاب شواهد غایب، مالک، تعهد و محرک بازنگری کنید.

کسانی را دعوت کنید که پیامدها را می‌فهمند، نه فقط کسانی که پیشنهاد را ارائه می‌کنند. برای یک تصمیم برنامه‌نویسی با هوش مصنوعی، این می‌تواند شامل یک مدیر مهندسی، یک توسعه‌دهنده‌ی باتجربه، امنیت، مدیریت پلتفرم یا تجربه‌ی توسعه‌دهندگان، مالی یا تدارکات و کسی باشد که پاسخ‌گوی قابلیت اطمینان انتشار است. کمیته‌ی بزرگ لازم نیست، اما نقشه‌ای که فقط حامی پروژه بکشد، نقاط کور او را به ارث می‌برد.

صفحه‌ی حاصل عدم‌قطعیت را حذف نمی‌کند. به آن شکلی می‌دهد که مدیریت بتواند از آن استفاده کند.

تعهدی را انتخاب کنید که از غافلگیری جان سالم به در ببرد

مدیران فناوری به‌ندرت یک آینده‌ی پایدار دریافت می‌کنند. با مدل‌های در حال تغییر، پذیرش ناهمگون، مقررات تازه، بودجه‌های متغیر، حوادث عملیاتی، تغییر ارائه‌دهندگان و شواهدی روبه‌رو می‌شوند که پس از شروع کار می‌رسد.

نقشه‌ی انتخاب سناریو به این واقعیت احترام می‌گذارد. تعهدی محدود تعریف می‌کند، جایگزین‌های واقعی را مقایسه می‌کند، بازه‌ی پیامدها را قابل‌دیدن می‌کند، شواهد را از ادعاها جدا می‌کند، ترجیحات سازمان را بیان می‌کند و واقعیت‌هایی را که می‌توانند انتخاب را برگردانند شناسایی می‌کند.

هدف پیش‌بینی آینده‌ی برنده نیست. هدف پرهیز از تصمیمی است که فقط درون یک داستانِ خوش‌بینانه کار می‌کند.

گزینه‌ای را انتخاب کنید که سودهایش معنادار، بده‌بستان‌هایش صریح و شکست‌های خطرناکش محدود است، و استدلالش وقتی شرایط تغییر می‌کند همچنان قابل‌فهم است. و بعد، پیش از آن‌که نتیجه گذشته را بدیهی جلوه دهد، انتخاب را ثبت کنید.