هر کسب و کار SaaS به مهار یک مدل تبدیل می شود

هر کسب‌وکار SaaS به مهار یک مدل تبدیل می‌شود، چه آن‌ها هنوز آن را درک کرده باشند یا نه.

به طور محدود، مردم اغلب یک «هبر» را با چارچوب‌هایی مانند LangGraph یا عوامل برنامه‌نویسی مانند Codex، Claude Code یا OpenCode مرتبط می‌کنند که یک API مدل بدون حالت را در ابزار کافی قرار می‌دهند و بیان می‌کنند که شما واقعا می‌توانید کار را انجام دهید.

من از اصطلاح "Harness" به طور گسترده به معنای تمام زیرساخت ها، رابط ها، زمینه و حالت هایی استفاده می کنم که یک LLM بدون حالت را احاطه کرده اند. یک هارنس می تواند از مهارهای فرعی اقتباس شده یا مخصوص کار تشکیل شده باشد (که ارکستراتور را "متا مهار" می نامند). «کارخانه نرم‌افزاری» مهاری است که قطعات آن مهارهای کوچک‌تری هستند - یکی که مشخصات را می‌نویسد، یکی که کد می‌نویسد، یکی که بررسی می‌کند - به‌علاوه چیزی در بالا که تصمیم می‌گیرد چه زمانی اجرا شود.

اگر این تعریف گسترده‌تر را بپذیرید (یا «همه» را با هر عبارتی که ترجیح می‌دهید جایگزین کنید)، من گمان می‌کنم که برای بسیاری از کسب‌وکارهای خدمات نرم‌افزاری، این مسیر را خواهید دید:

آنها خدمات نرم افزاری ساخته شده به روش سنتی SaaS-y را می فروشند.

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

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

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

با پیروی از این مسیر، شما در واقع شرکت خود را به یک مهار تبدیل کرده اید. کار برای تولید سرویس نرم افزاری از مردم به هارنس منتقل شده است.

وظایف اصلی توسط نمایندگان انجام می‌شود و «محصول» اکنون کاملا خروجی مدل است، با شرکتی که زمینه، ادغام‌ها و رابط‌های بازبینی انسان را فراهم می‌کند.

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

دانش دامنه شرکت، ابزار، مجوزها، حلقه‌های بررسی، زمینه و غیره همگی به مهار تجاری تبدیل می‌شوند.

بابت خواندن Shrivu’s Substack متشکریم! برای دریافت پست های جدید و حمایت از کار من به صورت رایگان مشترک شوید.

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

کاهش اصلی در واقع انتخاب مهار است که در آن ورودی های انسانی بیشترین اهمیت را دارند. به عنوان مثال:

یک تصمیم برای محصول می‌تواند از طرف نماینده‌ای باشد که در جلسات مشتریان سؤالاتی را برای نمایندگان مطرح می‌کند و سپس یک نسخه نمایشی محصول را برای محصول برای بررسی ترکیب می‌کند.

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

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

یک مهار خوب ارزش را برای مشتری به حداکثر می‌رساند در حالی که توجه انسان - کارمندان و مشتریان - را فقط در جایی که نیاز است صرف می‌کند.

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

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

بسته به خدمات، تمایز یک شرکت اغلب ناشی از مواردی مانند اعتماد، توزیع، کارایی و زمینه دامنه است. در دنیای عامل پس‌زمینه فعال، توانایی شما برای ساختن مهار - چگونه یاد می‌گیرد، چه چیزی را تماشا می‌کند، چگونه با ذائقه‌های انسانی ارتباط برقرار می‌کند، با چه سیستم‌هایی ادغام می‌شود - بیشتر و بیشتر این خواهد بود که چگونه این تمایز را حفظ کنید.

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

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

فکر می‌کنم ابزارهای توسعه‌دهنده هوش مصنوعی داخلی (مانند مواردی که از Ramp، Stripe، DoorDash و غیره دیده‌ایم) آغاز این کار هستند.

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

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

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

اگر این مدل ذهنی درستی است، باید انتظار داشته باشید که ببینید:

مقدار غیرمعمولی از ساختمان هارنس داخلی هم در سمت ساخت و هم در سمت فروش

ساختارهای سازمانی و نقش های فردی در اطراف جایگاه خود در مهار تجاری تغییر شکل می دهند

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

تمام نرم‌افزارهایی که یک شرکت نرم‌افزاری استفاده می‌کند (روی یا متصل به مسیرهای ساخت یا فروش اصلی) که باید هدلس باشند تا مهار بیرونی بتواند آن را اجرا کند.