این جواب محکم است؛ درست هم هست؟
پاسخ نمونه هنوز روی نمایشگر بود. مدیر عملیات همان جملهٔ آخر را دوباره خواند؛ جمله‌ای روشن، بی‌تردید و آمادهٔ استفاده.
«برای معیار پذیرش، این جواب خیلی محکم و روشن نوشته شده. از کجا می‌فهمیم درسته؟»
مدیر فناوری پیوند کنار پاسخ را باز کرد. بخشنامه‌ای ظاهر شد که شماره و تاریخ داشت و عبارت مورد استناد هم در آن پیدا می‌شد.
مدیر مالی کمی جلو آمد: «این همون نسخهٔ قبلی نیست؟ فکر می‌کنم بعداً اصلاحش کردیم.»
مدیر عملیات پوشهٔ مصوبات را باز کرد. چند لحظه بعد، دو سند کنار هم روی میز بود. موضوع یکی بود؛ حکمشان یکسان نبود.
مسئول ریسک و انطباق گفت: «پس منبع داشته، ولی باید اعتبار همین نسخه رو هم بررسی کنیم.»
مدیر فناوری پاسخ را از ابتدا خواند. این بار مکثش طولانی‌تر بود.
مدیرعامل برگهٔ معیارهای پذیرش را، که در جلسهٔ قبل آماده کرده بودند، به طرف خود کشید.
«اگر امروز این مورد اتفاقی پیدا نمی‌شد، با همون چند پاسخ خوب، آماده بودیم تحویلش بگیریم؟»
هیچ‌کس بلافاصله جواب نداد.
در درس چهاردهم موضوع تحویل و مسئولیت هر بخش را روشن کردیم و دیدیم هر ادعا باید معیار، دادهٔ آزمون، آستانهٔ پذیرش و مسئول اندازه‌گیری داشته باشد. در پایان همان جلسه، مدیر عملیات دربارهٔ درستی یک پاسخ قاطع پرسید. حالا کنار هم قرارگرفتن دو نسخهٔ بخشنامه نشان می‌دهد چرا داشتن منبع و نگارش محکم، بررسی را تمام نمی‌کند. باید مشخص کنیم چه آزمونی، با چه داده‌ای و به داوری چه کسی، شواهد کافی برای پذیرش دستیار فراهم می‌کند.
این درس اسلایدهای ۱۰۷ تا ۱۱۱ را به ترتیب دنبال می‌کند: صحت پاسخ، هزینهٔ انواع خطا، ارزیابی مستقل، تفاوت ادعاها و شواهد، و پذیرش چندلایه همراه با استقرار مرحله‌ای.
پاسخ قاطع، چه چیزی را اثبات می‌کند؟
باید سه مفهوم را از هم جدا کنیم: لحن قاطع، اطمینان مدل و صحت پاسخ. ممکن است پاسخ با ادبیاتی محکم بیان شود؛ ممکن است برای آن نشانه یا عددی از اطمینان هم نمایش داده شود. هیچ‌کدام به‌تنهایی نشان نمی‌دهد حکم ارائه‌شده دربارهٔ مسئلهٔ سازمان درست است.
در پروندهٔ ما، حتی پیدا شدن عبارت در سند نیز بررسی را تمام نمی‌کند. باید معلوم باشد سند معتبر است، نسخهٔ درست آن استفاده شده و حکم برای همین وضعیت کاربرد دارد. پاسخ به یک درخواست خرید، با استناد به بخشنامه‌ای که دیگر مبنای عمل نیست، با انتظار سازمان از پاسخ درست فاصله دارد؛ هرچند نقل عبارت کاملاً دقیق باشد.
بنابراین معیار پذیرش باید معنای «درست بودن» را برای همین کاربرد روشن کند. برای دستیار پاسخ‌گو از منابع سازمانی، می‌توان بررسی کرد که آیا پاسخ با منبع مصوب و معتبر سازگار است، به نسخهٔ قابل استفاده ارجاع می‌دهد و در صورت ابهام یا تعارض، مسیر ارجاع را رعایت می‌کند.
همهٔ این‌ها به حدود اختیار قبلی وابسته‌اند. دستیار پروندهٔ ما برای توضیح مقررات از منابع تأییدشده بررسی می‌شود؛ اختیار رد یا تصویب مستقل خرید به آن نداده‌ایم. پس رفتار صحیح در یک مورد مبهم می‌تواند توقف در پاسخ قطعی و ارجاع به مسئول مربوط باشد. آزمونی که فقط جواب نهایی را امتیاز بدهد و چنین ارجاعی را شکست بداند، ممکن است با سیاست مصوب سازمان ناسازگار باشد.
اعتبار پاسخ باید در نسبت با سؤال، منبع و حدود اختیار سنجیده شود. خوش‌بیانی پاسخ یکی از ویژگی‌های تجربهٔ کاربر است؛ پذیرش صحت به شواهد خودش نیاز دارد.
مدیر عملیات گفت: «پس توی آزمون، فقط نمی‌پرسیم جمله‌اش درسته یا نه؛ می‌پرسیم بر اساس کدوم نسخه و برای چه وضعیتی گفته.»
مسئول ریسک و انطباق نام دو بخشنامه را کنار هم نوشت: «این مورد رو هم نگه داریم؛ انتظار ما اینه که تعارض رو تشخیص بده یا ارجاع بده.»
مدیر مالی به گزارش نمونه اشاره کرد: «اینجا نوشته دقت بالا. اگر بیشتر جواب‌ها درست باشن، همین کافی نیست؟»
مدیرعامل گفت: «ببینیم اون جواب‌های غلط، کدوم‌ها هستن و چه اثری می‌ذارن.»
یک عدد دقت، هزینهٔ خطاها را نشان نمی‌دهد
در درس هفتم دربارهٔ هزینهٔ خطا صحبت کردیم. اینجا همان بحث به تصمیم پذیرش می‌رسد: آیا گزارشی که فقط یک عدد کلی از دقت نشان می‌دهد، برای تصمیم کافی است؟
مثال مزایای کارکنان، تفاوت هزینهٔ خطاها را روشن می‌کند. سامانه ممکن است به اشتباه فردی را واجد مزایا بداند؛ یا فرد واجد شرایط را فاقد مزایا معرفی کند. اولی می‌تواند پرداخت یا تعهد ناموجه ایجاد کند و پس از اصلاح، نارضایتی به همراه داشته باشد. دومی می‌تواند حق فرد را نادیده بگیرد و به شکایت و کاهش اعتماد برسد.
در دسترسی به اطلاعات نیز دو خطا داریم: باز کردن سند محرمانه برای فرد غیرمجاز، و محروم کردن کاربر مجاز از دسترسی لازم. پیامد این دو یکسان نیست. وزن آن‌ها هم باید با حساسیت اطلاعات و نیاز فرایند تعیین شود.
اگر خطاهای متفاوت را در یک میانگین جمع کنیم، بخشی از اطلاعات لازم برای پذیرش از بین می‌رود. ممکن است سامانه در سؤال‌های پرتکرار و کم‌خطر خوب عمل کند، اما در چند مورد حساس، رفتاری نشان دهد که با حدود پذیرفته‌شدهٔ سازمان سازگار نباشد.
برای پروندهٔ ما، گزارش آزمون باید خطاها را دست‌کم به اندازه‌ای تفکیک کند که تصمیم ممکن شود: استناد به سند منسوخ، پاسخ قطعی در وضعیت مبهم، ارجاع درست و رعایت محدودیت دسترسی، نتایج متفاوتی هستند. سپس برای موارد مهم، معیار و حد پذیرش متناسب تعیین می‌شود. موفقیت در سؤال‌های آسان نباید شکست یک کنترل ضروری را در میانگین پنهان کند.
این انتخاب، مسئولیت مالک کسب‌وکار و صاحبان ریسک را هم درگیر می‌کند. تیم فنی می‌تواند نتیجهٔ آزمون را اندازه بگیرد، اما تعیین اینکه کدام پیامد برای سازمان پذیرفتنی است، به تصمیم صاحبان اختیار نیاز دارد.
در «دقت ۹۵ درصد برای کارخانه چه معنایی دارد؟» همین مسئله را با دو سامانهٔ دارای دقت یکسان و هزینه‌های متفاوت نشان داده‌ام. مثال عددی آن یادداشت، هم هزینهٔ عیب‌های ازدست‌رفته و هشدارهای کاذب را حساب می‌کند و هم زمانی را که بررسی انسانی هشدارها از فرایند می‌گیرد.
مدیر مالی گفت: «در مزایا، هم پرداخت اشتباه مهمه، هم محروم‌شدن فردی که حق داره. نمی‌خوام یکی زیر عدد کلی اون یکی گم بشه.»
مدیر عملیات اضافه کرد: «برای خرید هم موارد تعارض سند و ارجاع رو جدا ببینیم.»
مدیر فناوری برگهٔ آزمون را جلو کشید: «نمونه‌هایی که تا حالا دیدیم رو پیمانکار آماده کرده. برای بررسی این موارد، باید مجموعهٔ آزمون خودمون رو هم مشخص کنیم.»
مدیرعامل پرسید: «و کسی که دربارهٔ نتیجه نظر می‌ده، از کجا می‌فهمه این نمونه‌ها نمایندهٔ کار واقعی ما هستن؟»
خط مبنا و آزمون مستقل را پیش از پذیرش آماده کنیم
خط مبنا، پیکرهٔ طلایی و ارزیابی مستقل، نقش‌های مکمل دارند. خط مبنا نشان می‌دهد کار امروز چگونه انجام می‌شود. پیکرهٔ طلایی مجموعه‌ای از موارد مرجع با پاسخ یا رفتار مورد انتظارِ بررسی‌شده است. ارزیابی مستقل امکان می‌دهد نتیجه را خارج از انتخاب و داوری انحصاری سازنده بسنجیم.
خط مبنا برای پروندهٔ ما می‌تواند رسیدگی فعلی کارشناسان باشد: پاسخ چگونه پیدا می‌شود، چقدر زمان می‌برد، چه خطاهایی رخ می‌دهد و چه مواردی ارجاع می‌شوند. بدون این شناخت، ممکن است یک قابلیت جذاب را ببینیم، اما ندانیم چه بهبودی ایجاد کرده یا چه هزینه‌ای به فرایند افزوده است.
پیکرهٔ طلایی نیز صرفاً فهرستی از سؤال‌ها نیست. برای هر مورد باید انتظار معتبر وجود داشته باشد. اگر خود سازمان هنوز دربارهٔ اعتبار دو بخشنامه توافق ندارد، همان اختلاف ابتدا باید توسط صاحب اختیار روشن شود؛ وگرنه آزمون، داوری دربارهٔ عملکرد سامانه را با اختلاف حل‌نشدهٔ سازمان مخلوط می‌کند.
این مجموعه باید سؤال‌های عادی و موارد مرزی مهم را پوشش دهد: تعارض اسناد، نبود منبع کافی، تفاوت مجوز کاربران و وضعیت‌هایی که پاسخ درستشان ارجاع است. بیست سؤال آسان و انتخاب‌شده برای نمایش، پوشش این موقعیت‌ها را اثبات نمی‌کند.
میان دادهٔ توسعه و شواهد پذیرش نیز باید فاصله باشد. مواردی که برای ساخت و اصلاح پاسخ‌ها استفاده شده‌اند، به‌تنهایی نشان نمی‌دهند سامانه با مسائل ندیده چگونه برخورد می‌کند. برای ارزیابی کور، بخشی از آزمون نهایی و پاسخ‌های مرجع آن از دسترس فرایند توسعه کنار گذاشته می‌شود و نتیجه با معیار از پیش تعیین‌شده بررسی می‌شود.
سازنده نباید تنها طراح آزمون و تنها داور پذیرش کار خودش باشد. پیمانکار همچنان آزمون داخلی انجام می‌دهد و شواهد ارائه می‌کند؛ مسئولیت کارفرما برای آماده‌کردن معیار، موارد مرجع و داوری مستقل باقی می‌ماند.
اینجا هم مسئولیت‌ها کلاه‌اند، اما تعارض نقش باید دیده شود. لازم نیست برای هر کلاه یک پست سازمانی تازه بسازیم؛ بااین‌حال، اینکه فرد نتیجهٔ کاری را که خودش ساخته، به‌تنهایی تأیید کند، استقلال ارزیابی ایجاد نمی‌کند. باید برای داوری آن بخش، بازبینی فرد یا مرجع دیگری پیش‌بینی شود.
برای عملی‌کردن این استقلال در رابطه با تأمین‌کننده، در «برای حکمرانی هوش مصنوعی، آیا باید کد منبع را ببینیم؟» دربارهٔ حق انجام آزمون مستقل و فراهم‌کردن محیط و اطلاعات لازم برای ممیز توضیح داده‌ام. این حق باید امکان راستی‌آزمایی را فراهم کند، حتی وقتی سازمان مالک کد یا وزن‌های مدل نیست.
مدیر عملیات گفت: «موارد مرجع رو با کارشناسی که صاحب همین فراینده بررسی می‌کنیم؛ جواب درست و محل ارجاع رو هم مشخص می‌کنیم.»
مسئول ریسک و انطباق ادامه داد: «چند مورد دسترسی و تعارض سند هم در آزمون مستقل می‌ذاریم. نتیجه‌شون رو جدا گزارش می‌کنیم.»
مدیر مالی پرسید: «پس نمایش هفتهٔ قبل چی رو ثابت کرده بود؟»
مدیر فناوری گفت: «اینکه در نمونه‌های نمایش‌داده‌شده، امکان پاسخ‌گویی وجود داره.»
مدیرعامل روی برگه نوشت: «ادعای هر مرحله را مشخص کنیم.»
دمو، پایلوت، محصول اولیه و سامانهٔ عملیاتی، ادعاهای متفاوتی دارند
دمو، پایلوت، MVP و سامانهٔ عملیاتی به پرسش‌های متفاوتی پاسخ می‌دهند. دمو امکان یک قابلیت را نشان می‌دهد؛ پایلوت، راهکار را در محیط واقعی اما محدود می‌آزماید. MVP یا حداقل محصول پذیرفتنی، شکل اولیه‌ای از محصول است که امکان شروع یادگیری معتبر دربارهٔ فرض‌های آن را فراهم می‌کند. در روش‌شناسی Lean Startup، هدف MVP آغاز چرخهٔ ساختن، سنجیدن و یادگرفتن است؛ از جمله اینکه آیا محصول مسئلهٔ مورد نظر کاربران را حل می‌کند و چه تغییری لازم دارد.
می‌توان یک MVP را در پایلوت آزمود: محصول، امکانات لازم برای آزمودن یک فرض مشخص را دارد و استفاده از آن در یک گروه یا محیط محدود بررسی می‌شود. بنابراین پایلوت لزوماً پیش از MVP قرار نمی‌گیرد. ترتیب، هم‌پوشانی و تکرار این فعالیت‌ها به مسئله، ریسک و فرض‌هایی که باید آزموده شوند وابسته است.
چهار نوع ادعا و شاهد
| نوع ادعا | پرسش | شاهد مورد نیاز |
|---|---|---|
| دمو | آیا امکان اولیهٔ مورد نظر در نمونهٔ ارائه‌شده نشان داده می‌شود؟ | اجرای قابل بررسیِ همان قابلیت، با شرایط و محدودیت‌های روشن |
| پایلوت | آیا راهکار در محیط واقعی اما محدود و کنترل‌شده نتیجهٔ مورد انتظار می‌دهد؟ | نتایج استفادهٔ محدود، مقایسه با خط مبنا و بررسی موارد مهم در همان دامنه |
| MVP | آیا شکل اولیهٔ محصول، امکان آزمودن فرض مشخصی دربارهٔ نیاز و رفتار کاربران را فراهم می‌کند؟ | مشاهده و سنجش رفتار کاربران با معیار مرتبط با آن فرض؛ نتیجه می‌تواند تأیید یا رد فرض باشد |
| سامانهٔ عملیاتی | آیا می‌توان خدمت را با پایداری، امنیت، پشتیبانی و ظرفیت لازم اداره کرد؟ | شواهد بار، امنیت، بازیابی، پشتیبانی و هزینه در شرایط بهره‌برداری مورد نظر |
یک دموی خوب برای بررسی امکان اولیه مفید است. برای نتیجه‌گیری دربارهٔ رفتار زیر بار واقعی، رسیدگی به رخداد، رعایت دسترسی‌ها یا هزینهٔ ادامهٔ خدمت، باید شواهد همان ادعاها فراهم شود.
در درس ششم پایلوت را به امکان اجرا، ارزش و قابلیت ادارهٔ راهکار پیوند دادیم. اکنون باید هنگام پذیرش مراقب باشیم نتیجهٔ یک آزمون محدود، به تعهدی گسترده‌تر تبدیل نشود. پذیرش پایلوت برای تعداد مشخصی کاربر و چند نوع سؤال، مجوز خودکار برای استفادهٔ همهٔ کارکنان در همهٔ فرایندها ایجاد نمی‌کند.
نام‌گذاری نیز به‌تنهایی کافی نیست. ممکن است چیزی «پایلوت» نامیده شود، اما کاربران واقعی بدون محدودیت به خروجی آن تکیه کنند. باید دامنهٔ کاربران، اطلاعات، اختیار و اثر خروجی روشن باشد تا ریسک واقعی با نام مرحله هماهنگ بماند.
در قرارداد و صورت‌جلسهٔ پذیرش، باید مشخص شود کدام نوع تحویل و کدام دامنهٔ استفاده تأیید می‌شود و تغییر یا گسترش آن به چه شواهدی نیاز دارد.
مدیر مالی کنار واژهٔ «تحویل» نوشت: «تحویل کدام مرحله؟»
مدیر عملیات گفت: «برای ما فعلاً همون استفادهٔ محدود مطرحه؛ چند کاربر مشخص و پاسخ از منابع تأییدشده.»
مدیر فناوری سر تکان داد: «با کنترل‌هایی که هنوز باید دوباره آزمون بشن.»
مدیرعامل گفت: «پس اگر این مرحله موفق شد، قدم بعدی رو هم با شرط مشخص باز می‌کنیم. از حالا ننویسیم آمادهٔ استفادهٔ عمومی.»
پذیرش چندلایه است؛ گسترش استفاده هم باید مرحله‌ای باشد
پذیرش را در پنج لایه بررسی می‌کنیم. برای دستیار پروندهٔ ما، هر لایه پرسش‌های خودش را دارد:
| لایه | پرسش پذیرش |
|---|---|
| فنی | پاسخ‌ها چقدر درست‌اند و تأخیر و پایداری در شرایط آزمون چگونه است؟ |
| عملیاتی | پایش، پشتیبانی و فرایند اجرا آماده‌اند و مسئول رسیدگی مشخص است؟ |
| امنیتی | دسترسی‌ها، ثبت رخداد و آزمون‌های امنیتی مورد نیاز نتیجهٔ قابل قبول دارند؟ |
| انسانی | کاربر آموزش دیده، محدودیت‌ها را می‌فهمد و می‌تواند از حق مداخله و ارجاع استفاده کند؟ |
| اقتصادی | هزینه و ظرفیت خدمت با ارزش مورد انتظار برای کسب‌وکار تناسب دارد؟ |
ممکن است پاسخ درست باشد، اما کاربر راه ارجاع خطا را نداند. ممکن است تجربهٔ استفاده خوب باشد، اما پشتیبانی برای زمان قطع خدمت آماده نباشد. ممکن است همهٔ این‌ها در استفادهٔ محدود خوب عمل کنند، اما هزینهٔ همان الگو در دامنهٔ بزرگ‌تر، با انتظار سازمان سازگار نباشد.
پس نتیجهٔ پذیرش باید به مجموعهٔ شواهد متکی باشد. برای هر لایه، مرجع تأیید و شرط عبور روشن می‌شود. یک فرد می‌تواند چند کلاه داشته باشد، اما باید معلوم بماند هر تأیید را با کدام مسئولیت و بر اساس کدام شواهد انجام داده است.
برای دستیار پروندهٔ ما، مسیر نمونهٔ استقرار در ارائه چنین است: حالت سایه، پایلوت محدود، آزمون بار و آزمون امنیتی، استفاده برای گروه محدود و استقرار کنترل‌شده.
در حالت سایه، می‌توان پاسخ سامانه را در کنار فرایند جاری بررسی کرد، بدون اینکه آن پاسخ مبنای اجرای اقدام سازمان شود. در پایلوت، استفاده در محدودهٔ مصوب انجام می‌شود. سپس شواهد بار و امنیت بررسی می‌شوند و با فراهم‌شدن شرایط، خدمت برای گروه محدودی گسترش می‌یابد. در مرحلهٔ آخر نیز کنترل دامنه، پایش و امکان مداخله باقی می‌ماند.
دامنه و ریسک کاربرد تعیین می‌کنند کدام بررسی‌ها هم‌زمان انجام شوند و کدام‌یک با تغییر شرایط تکرار شوند. این ترتیب به معنای موکول‌کردن امنیت به روزهای پایانی نیست؛ حداقل‌های لازم باید پیش از ورود هر کاربر و دادهٔ واقعی برقرار باشند. آزمون‌های بعدی، آمادگی برای دامنه و شرایط تازه را می‌سنجند.
هر افزایش در کاربران، منابع یا اختیار باید با شرایط عبور خودش همراه باشد. اگر شرطی برقرار نیست، تصمیم می‌تواند ادامهٔ آزمون در همان محدوده، اصلاح یا توقف گسترش باشد. پذیرش یک مرحله هم باید دقیقاً با همین حدود ثبت شود تا بعدها به تأییدی بی‌قیدوشرط تعبیر نشود.
این پیوند میان نتیجهٔ آزمون و اختیار ادامه یا توقف را در «وقتی استاندارد هست، اما کسی ملزم به آزمون نیست» بیشتر باز کرده‌ام: ارزیابی زمانی بر تصمیم اثر می‌گذارد که روشن باشد شکست یک کنترل، چه اصلاح یا محدودیتی را در پی دارد و چه کسی می‌تواند جلوی استقرار را بگیرد.
پذیرش کدام مرحله، با کدام شواهد؟
مدیرعامل برگه را به وسط میز برگرداند. کنار عنوان «معیار پذیرش»، حالا جای نام آزمون، مرجع داوری و دامنهٔ استفاده هم باز شده بود.
گفت: «اول آزمون مستقل رو کامل کنیم. بعد، دربارهٔ ادامهٔ استفاده در همون محدوده‌ای تصمیم بگیریم که شواهدش رو داریم.»
مدیر عملیات دو بخشنامه را داخل پوشه گذاشت: «این مورد هم جزو آزمون می‌مونه؛ با نتیجهٔ بررسی اعتبار نسخه‌ها.»
مسئول ریسک و انطباق گفت: «نسخهٔ سامانه، منابعی که باهاش آزمون شده و نتیجهٔ هر مورد رو هم باید نگه داریم. وگرنه بعداً نمی‌دونیم دقیقاً چی رو تأیید کردیم.»
مدیر مالی پرسید: «اگر بعد از پذیرش، بخشنامه یا خود سامانه عوض شد، این تأیید هنوز معتبره؟»
مدیرعامل به پوشه‌ای نگاه کرد که دیگر فقط چند پاسخ نمونه در آن نبود.
«پس باید معلوم کنیم چه شواهدی باقی می‌مونه و چه تغییری ما رو دوباره به ارزیابی برمی‌گردونه.»
در درس بعد، از همین‌جا ادامه می‌دهیم: پروندهٔ قابل حسابرسی چه چیزی باید در خود نگه دارد و چرا حکمرانی با تحویل پروژه پایان نمی‌یابد؟
این درس، پانزدهمین درس مجموعهٔ «حکمرانی هوش مصنوعی در سازمان» و تشریح اسلایدهای ۱۰۷ تا ۱۱۱ دوره است. درس قبل: در قرارداد هوش مصنوعی، دقیقاً چه چیزی تحویل می‌گیریم؟؛ اسلایدهای کامل دوره