کی اپی را که با هوش مصنوعی ساختهاید از نو بسازید (و کی به تکرار ادامه دهید)
هر اپی که با هوش مصنوعی ساخته شده به یک دوراهی میرسد: به آنچه دارید اضافه کنید، یا از نو شروع کنید. این هم اینکه چطور بفهمید کدام انتخاب واقعاً درست است.
اپی که کج رشد کرد
ماریا ساختن یک فرم سادهٔ پذیرش مشتری را شروع کرد. شش ماه بعد، او زمانبندی نوبت، یک صفحهٔ پرداخت، ایمیلهای یادآور خودکار، یک بخش یادداشت برای هر مشتری، و یک داشبورد که پیگیری میکرد آن هفته چند نفر رزرو کردهاند را داشت. تقریباً کار میکرد. اما هر چیز جدیدی که اضافه میکرد انگار چیز دیگری را خراب میکرد. اضافه کردن بخش یادداشت باعث شد جریان رزرو دیگر درست ذخیره نشود. درست کردن جریان رزرو یادآورها را خراب کرد.
از من پرسید: «دقیقاً کجا باید فقط از نو شروع کنم؟»
پاسخ صادقانه این است: به آن اندازه که فکر میکنید زیاد نه، اما نشانههای مشخصی هست که سخت میتوان در برابر دلیلِ بازسازیشان بحث کرد.
چرا بازسازی وسوسهانگیز به نظر میرسد (حتی وقتی اشتباه است)
وقتی یک اپ کند میشود، یا شروع به رفتار غیرقابلپیشبینی میکند، یا فقط دیگر آنطور که میخواهید به نظر نمیرسد — غریزه این است که دورش بیندازید و از نو شروع کنید. لوح سفید. هیچکدام از بار قدیمی نباشد.
آن غریزه معمولاً اشتباه است.
بازسازی بیشتر از آنچه مردم انتظار دارند طول میکشد. همهٔ موارد خاصی را که اپ فعلی شما بیسروصدا حل کرده از دست میدهید. آشناییای را که با نحوهٔ کار آن چیز ساختهاید از دست میدهید. و اغلب همان مشکلات ساختاری را از نو میسازید، چون مشکل واقعی اپ نبود — نبودِ وضوح دربارهٔ اینکه اپ قرار است چه کار کند بود.
اکثر اپهایی که با هوش مصنوعی ساخته شدهاند میتوانند از طریق تکرار نجات پیدا کنند. یک اپساز هوش مصنوعی خوب میتواند یک مدل دادهٔ گیجکننده را بازساختاربندی کند، یک صفحهٔ درهموبرهم را ساده کند، یا یک قابلیت را که از کنترل خارج شده مرتب کند. آنچه اهمیت دارد دانستن این است که کِی در قلمرو «درستش کن» هستید در برابر قلمرو «از نو شروع کن».
سه نشانه که واقعاً باید از نو بسازید
۱. ایدهٔ اصلی عوض شد، نه فقط قابلیتها
اگر ساختن یک ابزار پذیرش مشتری را شروع کردید و حالا یک SaaS B2B با اشتراک، تیمهای کاربری و یک مارکتپلیس عمومی میخواهید — این یک اپ متفاوت است. همان فناوری، یک محصول کاملاً متفاوت. تلاش برای تبدیل یکی به دیگری با لایهلایه کردن قابلیتها مثل تبدیل یک دوچرخه به یک ماشین با اضافه کردن قطعات است. در نهایت به چیزی میرسید که هیچکدام نیست.
پرسشی که باید پرسید: آیا این اپ را همانطور توصیف میکنم که وقتی اولین بار ساختمش توصیف کردم؟
اگر پاسخ نه است — اگر نام، مخاطب و ارزش اصلی همگی با آنچه در ابتدا ساختید فرق دارند — بازسازی احتمالاً انتخاب درست است. این فرصت را پیدا میکنید که برای آنچه واقعاً میخواهید طراحی کنید، به جای وصلهکاری دور و بر چیزی که برای چیز دیگری ساختید.
۲. هوش مصنوعی دیگر نمیتواند در اپ راهش را پیدا کند
این یک نشانهٔ عملی است، نه فلسفی. اپسازهای هوش مصنوعی با خواندن ساختار موجود اپ شما و اعمال تغییرات کار میکنند. وقتی یک اپ بارها وصله شده، ساختار ناهماهنگ میشود — داده در جاهای غیرمنتظره زندگی میکند، صفحهها بهصورت غیرمستقیم به چیزها ارجاع میدهند، دکمهها به منطقی وصلاند که از دکمههای دیگر کپی شده و هرگز مرتب نشده.
وقتی متوجه میشوید که هر تغییر چیزی نامرتبط را خراب میکند، یا هوش مصنوعی مدام همان اشتباه را میکند (مثل تشخیص نادرست اینکه یک قابلیت به کدام بخش اپ تعلق دارد)، شاید وارد قلمرو «بدهی ساختاری» شدهاید.
بازسازی این را با جادو حل نمیکند — اما به شما اجازه میدهد از همان ابتدا، با تصویر کامل در ذهن، تمیز بسازید.
۳. اپ کاربر دارد اما دارد جلوی آنها را میگیرد
اگر آدمهای واقعی دارند از اپ شما استفاده میکنند و مدام به همان دیوار میخورید — «به X نیاز داریم ولی هیچ راهی برای اضافه کردنش بدون از نو ساختن همه چیز نیست» — این یک نشانهٔ مشروع برای بازسازی است. نه به این خاطر که اپ بد است، بلکه چون برای نسخهٔ کوچکتری از مشکل ساخته شد تا آنچه واقعاً باید حل کنید.
این یک مشکل خوب برای داشتن است. یعنی اپ آنقدر خوب کار کرد که مردم دارند جدی از آن استفاده میکنند. بازسازی در این مرحله یک شکست نیست — یک فارغالتحصیلی است.
قبل از بازسازی چه کنید
حتی اگر تصمیم به بازسازی گرفتهاید، اول این کارها را بکنید:
بنویسید چه چیزی جواب داد. اپ فعلیتان را مرور کنید و هر چیزی را که کاربران واقعاً استفاده میکنند فهرست کنید. این قابلیتها تقاضای ثابتشده دارند. باید از روز اول در اپ جدید باشند.
بنویسید چه چیزی مشکل ایجاد کرد. نه فقط «این کند بود» یا «این زیاد خراب میشد» — دقیق باشید. «قابلیت یادداشت با جریان رزرو تداخل داشت چون هر دو داده را در همان رکورد کاربر ذخیره میکردند.» میخواهید درسها را با خود ببرید، نه کد را.
یک حد دامنه برای بازسازی تعیین کنید. بزرگترین خطر بازسازی، خزش دامنه است. تصمیم میگیرید همه چیز را از نو بسازید، و دو ماه بعد هنوز تمام نشده چون مدام قابلیتهای «حالا که داریم این کار را میکنیم» اضافه میکنید. بازسازی باید قابلیتهای کارآمد اپ قدیمی بهعلاوهٔ یکی دو چیزی که واقعاً مسدود شده بودند را عرضه کند. همه چیز دیگر بعداً اضافه میشود.
کی به تکرار ادامه دهید (در اکثر مواقع)
اپتان کند بارگذاری میشود؟ تکرار کنید — این معمولاً یک مشکل کوئری داده است یا بارگذاری همزمان چیزهای زیاد.
طراحیتان قدیمی به نظر میرسد؟ تکرار کنید — یک نوسازی طراحی صددرصد در یک اپساز هوش مصنوعی، بدون دست زدن به منطق زیرین، شدنی است.
یک قابلیت کلیدی ناشیانه به نظر میرسد؟ تکرار کنید — فقط همان قابلیت را از نو بسازید، نه کل اپ را.
قابلیتهای زیادی اضافه کردید و چیزها پراکنده به نظر میرسند؟ تکرار کنید — حذف قابلیتها و ساده کردن ناوبری بسیار سریعتر از یک بازسازی کامل است، و اغلب مؤثرتر.
قاعدهٔ سرانگشتی: اگر مدل داده هنوز برای آنچه میخواهید انجام دهید معنا دارد، تکرار کنید. اگر مدل داده شکل اشتباهی برای محصول دارد، از نو بسازید.
اپ ماریا
اپش را با هم مرور کردیم. ساختار اصلی — مشتریها، نوبتها، پرداختها — در واقع خوب بود. آشفتگی از یک قابلیت یادداشت میآمد که به شکلی که با نحوهٔ ذخیرهٔ رکوردهای مشتری تداخل داشت، به آن سنجاق شده بود.
به جای بازسازی، او دقیقاً به اپساز گفت چه اتفاقی دارد میافتد: «بخش یادداشت و جریان رزرو دارند اطلاعات را در جاهای همپوشان ذخیره میکنند، و این باعث تداخل میشود. میخواهم یادداشتها را طوری بازساختاربندی کنم که کاملاً از رکورد رزرو جدا باشند.» دو جلسه بعد، درست شد. بقیهٔ اپ دستنخورده ماند.
شش ماه قابلیت انباشته، از دست نرفت.
پرسش واقعی
پیش از آنکه تصمیم به بازسازی بگیرید، بپرسید: مشکل از اپ است، یا از وضوح من دربارهٔ اینکه اپ باید چه کار کند؟
در اکثر مواقع، پاسخ وضوح است. و وضوح به بازسازی نیاز ندارد. فقط نیاز دارد که با اپساز هوش مصنوعیتان دربارهٔ آنچه واقعاً میخواهید دقیق باشید.
از همانجا شروع کنید. بازسازی همیشه در دسترس است. یک هفتهٔ دیگر هم همانجا خواهد بود.
اگر دارید سعی میکنید بفهمید اپتان واقعاً به چه نیاز دارد — چه یک تغییر کوچک باشد چه یک شروع تازه — Proyecta جای خوبی برای فکر کردن دربارهٔ آن است. چیزی کوچک بسازید، ببینید چه چیزی دوام میآورد، و از همانجا رشد کنید.