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