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