پروژه موفق شد؛ آیا تصمیم ما هم درست بوده است؟

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

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

نتیجه مهم است، اما به تنهایی حکم نمی دهد

«سوگیری نتیجه» وقتی رخ می دهد که دانستن نتیجه، قضاوت ما درباره ی تصمیم قبلی را تغییر دهد. این خطا فقط در قضاوت فردی نیست؛ نظام پاداش، ارتقا، بازبینی پروژه و گزارش دهی به مدیران هم ممکن است به ریسکِ خوش شانس جایزه بدهند و تیمی را که درست کار کرده اما بداقبال بوده تنبیه کنند.

خودکارسازی این گرایش را از بین نمی برد. یک آزمایش داوری شده در سال ۲۰۲۵ درباره ی تصمیم های مالیِ واگذارشده به انسان ها و الگوریتم ها نشان داد ارزیابان، چه انتخاب مستقیم انجام شده بود و چه به الگوریتم سپرده شده بود، به شدت تحت تأثیر نتیجه بودند. زمینه ی پژوهش مالی بود، نه تحویل محصول هوش مصنوعی، اما هشدار مدیریتی اش به خوبی قابل تعمیم است: تغییر این که چه کسی یا چه چیزی انتخاب می کند، تضمین نمی کند که آدم ها بعداً منصفانه درباره اش داوری کنند.

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

نتیجه باید به ما کمک کند دفعه ی بعد بهتر تصمیم بگیریم؛ نباید باعث شود فراموش کنیم هنگام تصمیم گیری چه اطلاعاتی در دسترس مان بود.

این مرز سه چیز را هم از هم جدا می کند که اغلب در یک چیز فشرده می شوند:

• کیفیت تصمیم: آیا تیم مسئله را درست شناخت، گزینه های جدی را سنجید و با توجه به ریسک، به اندازه ی لازم تعهد کرد؟
• کیفیت اجرا: آیا تصمیم با دقت کافی اجرا و پایش شد؟
• نتیجه ی نهایی: وقتی تصمیم در عمل با کاربران، سامانه ها، زمان بندی و اتفاق های پیش بینی نشده روبه رو شد، چه رخ داد؟

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

تصمیم را با اطلاعات همان روز بسنجید

برای چند دقیقه نتیجه ی نهایی را کنار بگذارید.

تصمیم را با همان اطلاعاتی بررسی کنید که هنگام گرفتنش در دسترس داشتید. یک یادداشت کوتاه و تاریخ دار از این موارد کمک می کند:

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

لازم نیست برای هر تغییر کوچک در پرامپت چنین پرونده ای بسازید. این کار را برای تصمیم های پرهزینه، دشوار برای بازگرداندن، حساس یا مهمی انجام دهید که احتمال دارد بعداً دوباره درباره شان گفت وگو کنید.

آن سابقه را دست کاری نکنید: عدم قطعیت هایی را که آن موقع داشتید پاک نکنید، پیش بینی تقریبی را طوری ننویسید که انگار دقیق بوده و گزینه ای را که بعداً جذاب به نظر می رسد از قلم نیندازید. اگر استدلال تیم جایی ثبت نشده، از تیکت ها، گزارش ارزیابی، سند طراحی، صورت جلسه و پیام های همان زمان کمک بگیرید. هرجا مطمئن نیستید، همان را بنویسید؛ حافظه ی امروز را جای واقعیت دیروز نگذارید.

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

ببینید انتخاب اولیه چقدر پشتوانه داشت

اگر می توانید، پیش از دیدن نتیجه یا دست کم بدون توجه به آن، پنج سؤال زیر را درباره ی تصمیم بپرسید.

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

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

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

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

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

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

بعد از این مرور، نتیجه را دوباره وارد بحث کنید.

تفاوت انتظار و واقعیت را پیدا کنید

حالا نتیجه به عنوان شاهد وارد بازبینی می شود. آن را با بازه ای که تیم انتظار داشت مقایسه کنید و فاصله را توضیح دهید.

چهار دسته مفیدند:

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

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

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

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

موفقیت اتفاقی، ریسک را پاک نمی کند

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

تصور کنید انتقال داده ها سر وقت تمام می شود، با این که هیچ کس راه برگشت به نسخه ی قبلی را امتحان نکرده است. یا ایجنتی با دسترسی گسترده به ابزار ها ۵۰۰ کار را بدون دردسر انجام می دهد، هرچند گزارش رویدادهایش ناقص است. یا کارکنان از محصول یک فروشنده استقبال می کنند، چون مدیران ارشد موقتاً همه را به استفاده از آن ملزم کرده اند.

هر سه پروژه را می توان موفق اعلام کرد؛ بااین حال نتیجه نشان نداده که در روش کارشان چه نقصی وجود داشته است.

پس از چنین موفقیتی هم یک بازبینی کوتاه انجام دهید:

• ببینید چه کنترل، فرض یا شاهدی در کار نبود.
• توضیح دهید اگر اوضاع بد پیش می رفت، چه شکستی ممکن بود رخ دهد.
• پیامد آن شکست و امکان جبرانش را بسنجید.
• پیش از گسترش کار، دست کم یک کنترل مفید اضافه کنید.
• نتیجه ی خوب را ثبت کنید، اما آن را تضمینی برای دفعات بعد ندانید.

این کار نمی گذارد موفقیت تیم را بی احتیاط کند. مدیران هم می توانند پروژه ای موفق را بررسی کنند، بی آن که زحمت تیم را نادیده بگیرند: «نتیجه خوب بوده، اما در روند تصمیم گیری ریسکی پذیرفتیم که نباید دوباره بپذیریم.»

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

نتیجه ی منفی را با تصمیم بد یکی نگیرید

از آن طرف، هر کاری را که نتیجه ی مطلوبی نداشته شکستِ قابل سرزنش ندانید.

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

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

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

نتیجه ی منفیِ یک آزمایش مسئولانه باید به یکی از این سه تصمیم برسد:

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

اگر هر نتیجه ی منفی تنبیه داشته باشد، افراد سراغ پروژه هایی می روند که شکست در آن ها بعید است، معیار ها را آسان تر می گیرند، شاهد های ضعیف را پنهان می کنند و خبر بد را دیر می گویند. اما اگر هر شکستی را جشن بگیریم، بی دقتی را تشویق کرده ایم. پاداش باید برای آزمایشی باشد که پرسشی درست را با روشی حساب شده پاسخ می دهد؛ نه برای شکست خوردن به خودی خود.

همین انصاف را در تصمیم های دیگر هم به کار ببرید

این روش برای هر تصمیمی مفید است که نتیجه اش نامطمئن است و ممکن است قضاوت ما را درباره ی خودمان تحت تأثیر قرار دهد.

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

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

این بررسی نمی گذارد به دو نتیجه گیری شتاب زده برسید: «این بار جواب داد، پس همیشه همین کار را بکنم» یا «بد تمام شد، پس از اول تصمیم احمقانه ای بود». یک نتیجه ی تنها به ندرت چنین حکم هایی را ثابت می کند.

ارزیابی کل پروژه به گفت وگویی گسترده تر با تیم نیاز دارد. در یادداشت بازنگری های پروژه که تیم های هوش مصنوعی را بهتر می کنند نوشته ام چطور شواهد مربوط به تحویل، اطمینان پذیری، کار تیمی و اقدام های بعدی را کنار هم بگذاریم. مقاله ی حاضر دامنه ی محدودتری دارد: یک تصمیم مهم را بررسی می کند تا نتیجه ی نهایی همه ی قضاوت ها را تحت تأثیر قرار ندهد.

بازبینی باید به دو اقدام برسد

بازبینی قرار نیست با قضاوت درباره ی آدم ها تمام شود؛ باید کمک کند دفعه ی بعد تصمیم بهتری بگیریم.

دو تغییر را ثبت کنید:

• تغییر در روش کار: مثلاً روشن کردن مسئولیت ها، بررسی گزینه های بیشتر، گرفتن تأیید لازم یا تعیین زمان مشخص برای بازبینی.
• تغییر در شواهد: مثلاً افزودن نمونه ای به آزمون ها، پایش یک نشانه ی تازه، ثبت هزینه یا توجه به نوع مشخصی از خطا.

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

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

نمی توانیم شانس را از تصمیم گیری حذف کنیم. تصمیم های کاری و شغلی همیشه تحت تأثیر چیز هایی هستند که کنترلشان دست ما نیست. اما می توانیم نگذاریم تنها نتیجه ی تصادفی باشد که از آن یاد می گیریم.

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