وقتی یک محصول به دو محصول تبدیل میشود: چطور اپ ساختهشده با هوش مصنوعیتان را بدون شروع از صفر تقسیم کنید
اپ ساختهشده با هوش مصنوعیتان بهعنوان یک محصول شروع شد. بعد فهمیدید که در نهان دو محصول است. این چیزی است که چطور یک اپ هوش مصنوعی را تمیز تقسیم کنید — بدون رها کردن آنچه پیشتر عرضه کردهاید.
با یک ایده شروع کردید. آن را به اپساز هوش مصنوعیتان توصیف کردید، تماشا کردید که صفحهها را تولید میکند، گوشههای ناهموار را اصلاح کردید، و چیزی واقعی عرضه کردید. مردم شروع به استفاده از آن کردند. و بعد، اول آرامآرام، یک الگو در بازخوردها پدیدار شد: نیمی از کاربرانتان یک چیز میخواستند، نیم دیگر چیزی دیگر. آنها بر سر یک قابلیت دعوا نمیکردند. آنها دو محصول متفاوت را درخواست میکردند.
این لحظهای است که خیلی از بنیانگذاران وحشت میکنند و یک پروژهٔ دوم را از صفر شروع میکنند. نباید این کار را بکنند. وقتی یک محصولتان از آب درمیآید که دو محصول است، راه تمیزتری برای تقسیم یک اپ هوش مصنوعی وجود دارد — و معمولاً بیشتر آنچه را که قبلاً ساختهاید نگه میدارد. این پست دربارهٔ این است که چطور تقسیم را تشخیص دهید، کی انجامش دهید، و سه شکلی که تقسیم معمولاً به خود میگیرد.
چطور میفهمید دو محصول دارید
این سیگنال تقریباً هیچوقت شبیه یک درخواست قابلیت نیست. شبیه اصطکاک است.
یک اپ بهرهوری که دیدم این مسیر را طی میکند، داستان روشنی داشت. بهعنوان یک «برنامهریز شخصی» فروخته میشد. کاربران در دو طعم ظاهر شدند. یک گروه از آن برای برنامهریزی هفتهٔ خودشان استفاده میکردند و مثل یک دفترچهٔ یادداشت خصوصی با آن رفتار میکردند. گروه دیگر تیمهای کوچک اداره میکردند و میخواستند کارها را به دیگران واگذار کنند. هر دو بهقدر کافی راضی بودند که به استفاده از همان محصول ادامه دهند، اما هر انتشار جدید یک گروه را راضی و گروه دیگر را آزرده میکرد. تیم فکر میکرد یک مشکل اولویتبندی قابلیت دارد. آنها در واقع یک مشکل برندینگ داشتند. آنها یک اپ شخصی و یک اپ تیمی داشتند که یک کدبیس، یک صفحهٔ خانه و یک صفحهٔ قیمتگذاری را با هم به اشتراک میگذاشتند.
وقتی یکی از اینها شروع به درست بودن کند، میفهمید که از آن خط عبور کردهاید:
- لندینگپیج شما مجبور است پیشنهاد فروش واقعیاش را پشت زبان کلیگو پنهان کند، چون دو مخاطب به یک کلمات یکسان باور نمیکنند.
- هر قابلیت جدید یک قید «اما برای آن نوع دیگرِ کاربر باید جور دیگری کار کند» دارد.
- پاسخهای پشتیبانیتان شاخهشاخه میشوند: «اگر برای خودتان استفاده میکنید…» در برابر «اگر یک تیم را مدیریت میکنید…».
- تعداد قابلتوجهی از کاربران دو حساب جداگانه نگه میدارند تا دو حالت را از هم جدا نگه دارند.
اگر دو یا چند مورد از اینها را میبینید، مشکل قابلیت ندارید. یک تقسیم محصول دارید که منتظر اتفاق افتادن است.
سه شکل یک تقسیم
لازم نیست از روز اول یک شکل را انتخاب کنید. معمولاً میتوانید اول سبکترین را امتحان کنید و بعد ارتقا دهید. اما مفید است که پیش از شروع به توصیف آن برای اپساز هوش مصنوعیتان، فهرست گزینهها را بدانید، چون کلماتی که استفاده میکنید شکل آنچه تولید میشود را تعیین میکند.
شکل ۱: یک اپ، دو در
سبکترین نسخه. یک کدبیس را نگه میدارید. در اولین اجرا یک پرسش اضافه میکنید — «اینجا برای خودتان آمدهاید یا برای یک تیم؟» — و از پاسخ برای نمایش مجموعهٔ متفاوتی از صفحهها و یک ناوبری متفاوت استفاده میکنید. همان مخزن داده. همان ورود. همان صورتحساب. فقط یک سطح متفاوت.
اگر آن را بهعنوان یک «اپ دوحالته» توصیف کنید، بیشتر اپسازهای هوش مصنوعی این را خوب از پس برمیآیند. چیزی که باید مراقبش باشید این است که دو حالت نباید صفحههایی را با نمایشوپنهانهای شرطی در همهجا به اشتراک بگذارند. آخرش شبیه یک اپ شلوغ میشود که وانمود میکند دو اپ است. به اپساز بگویید که دو در جدا هستند — صفحههای خانهٔ متفاوت، صفحههای تنظیمات متفاوت، حالتهای خالیِ متفاوت. آن چند صفحهای که واقعاً همپوشانی دارند (تنظیمات حساب، صورتحساب) میتوانند به اشتراک گذاشته شوند.
کی کار میکند: وقتی دو مخاطب قاببندی متفاوتی میخواهند اما همان اشیای زیرین را. مثال برنامهریز در برابر تیم اینجا جا میگیرد. آنچه زمانبندی میکنید همچنان یک کار است؛ فقط قواعد حول واگذاری، اشتراکگذاری و اطلاعرسانی تغییر میکند.
کی کار نمیکند: وقتی دو مخاطب کاملاً اشیای متفاوتی انتظار دارند. یک «پورتال مشتری» و یک «ابزار مدیریت داخلی» تقریباً هیچ همپوشانیای ندارند، حتی اگر به نظر برسد دربارهٔ همان کسبوکار هستند.
شکل ۲: دو اپ، یک backend
شکل میانی. جلوی محصول را به دو اپ جداگانه تقسیم میکنید — دو URL، دو لندینگپیج، دو جریان آنبوردینگ، دو جدول قیمت — اما هر دو از همان پایگاه دادهٔ زیرین میخوانند. یک مشتری میتواند روی هر دو حساب داشته باشد. یک ادمین میتواند دادهٔ هر دو را ببیند.
این کاری است که ما اخیراً در شرکتی که این بلاگ را اداره میکند انجام دادیم. یک اپ داشتیم که سعی میکرد به دو مخاطب خدمت کند: مهندسانی که پلتفرم ایجنت ما را ارزیابی میکردند، و سازندگانی که از اپساز هوش مصنوعی ما استفاده میکردند. همان backend، همان احراز هویت، همان پایگاه داده — اما frontend دو سر درآورده بود و پیامرسانی گیجکننده بود. آن را به دو اپِ frontend تقسیم کردیم، یکی برای هر مخاطب. backend دقیقاً همان ماند.
این شکل وقتی پاسخ درست است که:
- دو مخاطب به دلایل متفاوتی خرید میکنند.
- با متن بازاریابیِ مخاطب دیگر گیج یا دلزده میشوند.
- دادهای که برایشان مهم است عمدتاً همان شکل را دارد، اما جور دیگری قاببندی شده است.
- نمیخواهید دو پایگاه داده یا دو راهاندازی صورتحساب را نگهداری کنید.
به اپساز هوش مصنوعیتان بگویید میخواهید «یک اپِ frontend دوم که API موجود را به اشتراک میگذارد». بیشتر اپسازهای مدرن هوش مصنوعی میتوانند یک پروژهٔ خواهر داربستبندی کنند و آن را به backend موجود شما اشاره دهند. تلهای که باید از آن دوری کنید: کپی-پیست کلمهبهکلمهٔ اجزای اپ اول و بعد ویرایش کردن هر دو نسخه تا ابد. از اپساز بخواهید بخشهای مشترک (صفحههای احراز هویت، ویجتهای فرم رایج) را در یک کتابخانهٔ کوچک استخراج کند که هر دو اپ از آن استفاده کنند. این کار بعدها ماهها اصلاح تکراری را برایتان صرفهجویی میکند.
شکل ۳: دو اپ، دو backend
سنگینترین تقسیم. شما واقعاً دو محصول دارید. آنها داده را به اشتراک نمیگذارند، کاربران را به اشتراک نمیگذارند، و نباید نقشهٔ راه را به اشتراک بگذارند. حرکت درست این است که کاملاً جدایشان کنید: کدبیسهای جدا، پایگاههای دادهٔ جدا، دامنههای جدا.
این کمتر از آنچه مردم فکر میکنند حرکت درستی است. وسوسهکننده است چون تمیز به نظر میرسد. واقعیت این است که دو اپ کاملاً جدا یعنی دو تا از هر چیز برای سر پا نگه داشتن — دو خط استقرار، دو شیفت آمادهباش، دو یکپارچهسازی صورتحساب، دو سند راهنما. به این شکل دست نزنید مگر اینکه محصولات واقعاً هیچ همپوشانیای نداشته باشند. یک آزمون خوب: اگر یک کاربر محصول الف هرگز کاربر محصول ب نمیشود، احتمالاً به شکل ۳ نیاز دارید. اگر بیشتر کاربرانتان بهطور محتمل هر دو را میخواهند، تقریباً مطمئناً شکل ۲ را میخواهید.
وقتی این کار را با یک اپساز هوش مصنوعی انجام میدهید، آسانترین حرکت این است که پروژهٔ موجودتان را بهعنوان نقطهٔ شروع کپی کنید برای دومی، بعد از اپساز بخواهید قابلیتهایی را که به آن تعلق ندارند حذف و آنهایی را که تعلق دارند اضافه کند. پروژهٔ دوم را از یک بوم خالی شروع نکنید. در ساختن اولی چیزهای زیادی یاد گرفتهاید، و اپساز هوش مصنوعی اگر بگذارید آن بافتار را برمیدارد.
پیش از تقسیم هر چیزی چه کاری انجام دهید
پیش از اینکه تقسیم را به اپساز هوش مصنوعیتان توصیف کنید، سه کار کوچک انجام دهید. ارزششان بیشتر از آن چیزی است که به نظر میرسد.
اول، صفحهٔ خانهٔ جدید را برای هر طرف بنویسید. دو پاراگراف برای هر کدام. پیشنهاد فروش، مخاطب، آن یک کاری که میخواهید انجام دهند. اگر نمیتوانید دو صفحهٔ خانهٔ متفاوت بنویسید، در واقع هنوز دو محصول ندارید — فقط دو بخش از یک محصول دارید، و باید آن را با پیامرسانی حل کنید، نه با معماری.
دوم، فهرست کنید کدام صفحهها مشترکاند و کدام نیستند. صادق باشید. «ورود مشترک است. آنبوردینگ متفاوت است. داشبورد متفاوت است. تنظیمات عمدتاً مشترک است. صورتحساب مشترک است.» این فهرست به همان بریفی تبدیل میشود که به اپساز هوش مصنوعی میدهید. کلی رفتوبرگشت را صرفهجویی میکند.
سوم، تصمیم بگیرید چه چیزی در زیرین یکسان است. کاربران یکسان؟ دادهٔ یکسان؟ پرداختهای یکسان؟ هر «بله» شما را به سمت شکل ۱ یا ۲ میکشد. هر «نه» شما را به سمت شکل ۳ میکشد. هیچ پاسخ درستی وجود ندارد — فقط پاسخی که با کارکرد واقعی محصول شما مطابقت دارد.
بعد از تقسیم چه چیزی تغییر میکند
دو چیز آسانتر میشود و یک چیز سختتر.
بازاریابی آسانتر میشود. هر اپ پیشنهاد فروش روشن خودش را میگیرد. هر لندینگپیج میتواند بدون طفره رفتن با یک مخاطب صحبت کند. نرخ تبدیل شما معمولاً دستکم در یک طرف بالا میرود، گاهی هر دو.
آنبوردینگ آسانتر میشود. یک کاربر بار اول روی صفحهای فرود میآید که دربارهٔ خودش است، نه صفحهای که سعی میکند دربارهٔ همه باشد.
چیزی که سختتر میشود همگام نگه داشتن بخشهای مشترک است. اگر یک باگ را در جریان ورود اصلاح کنید، میخواهید در هر دو اپ اصلاح شود. اگر ظاهر صفحهٔ صورتحساب را تغییر دهید، میخواهید هر دو اپ آن را بازتاب دهند. انضباطی که نیاز دارید — و این چه با یک اپساز هوش مصنوعی وایب کدینگ میکنید چه با یک تیم از توسعهدهندگان انسانی میسازید درست است — این است که بخشهای مشترک را واقعاً مشترک نگه دارید. تکرار نکنید. شاخه نزنید. یا صفحهٔ مشترک را در یک کتابخانهٔ کوچک استخراج کنید که هر دو اپ از آن استفاده کنند، یا بپذیرید که دو اپ واقعاً جدا دارید و مسئولیتش را بپذیرید.
یک پرسش کوچک برای پایان
اگر پیشنهاد فروش اپ فعلیتان را پیش روی پنج غریبه میگذاشتید و هر کدام جور متفاوتی توصیفش میکردند — اما در دو سطل متمایز — احتمالاً همین حالا با آن تقسیم زندگی میکنید. تنها پرسش این است که آیا به پرداخت مالیات یک محصول گیجکننده ادامه میدهید، یا زحمت صادق بودن دربارهٔ دو محصول بودن را به جان میخرید.
لازم نیست امروز تصمیم بگیرید. اما دفعهٔ بعد که اپساز هوش مصنوعیتان میپرسد «بعد چه چیزی بسازم؟»، در نظر بگیرید که مفیدترین پاسخ شاید یک قابلیت جدید نباشد. شاید یک درِ ورودی جدید باشد.
اگر این مطلب با شما همخوانی داشت، شاید نوشتهٔ پیشینمان دربارهٔ ساختن برای تیمتان در برابر ساختن برای مشتریان را هم بپسندید — همان طعمِ تصمیم، یک قدم زودتر در زندگی محصول شما.