بهترین پروژه هوش مصنوعی، جذاب ترین ایده جلسه نیست

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

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

اولین پرسش، محل درد است

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

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

یک صفحه برای هر کاربرد کافی است

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

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

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

آزمایش را طوری طراحی کنید که امکان رد شدن داشته باشد

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

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

معیار ارزش را در محل کار پیدا کنید

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

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

ارزش و امکان اجرا را روی دو محور مستقل ببینیم

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

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

دشواری پنهان در تعریف خروجی

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

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

هزینه فرصت را هم وارد انتخاب کنید

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

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

مرحله کشف را از مرحله ساخت جدا کنید

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

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

بعد از انتخاب پروژه، توافق را مکتوب کنید

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

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

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